Ciaran Cahill

Greenhorn
+ Follow
since Aug 03, 2007
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ciaran Cahill

Hi Jean,
If you send an email to the certification support they should be able to update it manually. At least they did for me. The results are not being updated in the other database automatically due to a problem Sun are having....
Hello
When I check on the www.certmanager.net/sun_assignment site it says I have passed.....
woo hoo!
(there is an actual score there with the comments)

But when I check on the general http://www.certmanager.net/sun site, it still says Pending.
Is there a delay between when the sun_assignment page is updated and when the other page is updated? It is hardly a dummy score?
I would say go with the text document. It sounds like an absolute requirement, there's no point in risking it. You could do a UML diagram and export it as a JPG image - they should be able to view that without any problems.
I think the idiom for locking is :

mylock.lock();
try {

...
}
catch {

} finally {
mylock.unlock();
}

This ensures that the lock is released on all paths out of the method
Hi just a quick question about Collections.synchronizedList and synchronizedMap:

Is it necessary to use this for the main lists you might have in your database (like the main list of records or the list of locked records) if you always synchronize before using them?
E.g. for my main list of records I have a corresponding Lock that guards it and which must be acquired before modifying it (design rule). This should guarantee that the list will not be modified by more than one thread at once - or is there a need for a synchronizedList? Just to make sure
thanks
Hi guys,
Just on a related issue, in my database class I am implementing the interface given by Sun. However I also need to throw extra execptions in addition to the ones in the interface. The way I am getting around this is to create a subclass of RuntimeException, which allows me to throw the extra exception... because it's not checked.
Is this acceptable? Nearly all of my other exceptions are checked exceptions (they extend Exception directly).
Hi,
I know there are a lot of locking questions already but anyway:

In my database class, I have several resources, such as the list of records, the list of reserved records and the random access file used to access the database binary file.
At the moment I am controlling access to all of these using a single Reentrant lock. If I need access to any of these 3 resources, I use this one lock. I also have a single Condition that is used together with this lock. This simplifies the locking and makes it easier to track down deadlocking.

I just have one doubt:
Would it be better to have a Reentrant lock for each of the 3 resources, and lock on all 3? This would make it clear which resources are being locked. - My only doubt is that 3 nested locks might not be necessary and might be bad style..

thanks!
Hi Alex,
There is a problem using the thread ID to identify the client when you are using RMI. RMI does not actually guarantee that it will always use the same thread to execute a task as the thread that enters the method. It actually switches the threads around in the background.
I only found this out yesterday and I am trying to submit in the next few days!! I was sure you would be guaranteed to always have the same thread in this situation.
Hi Alex
Thanks you're a legend. This is what I was wondering about. I thought you would have to make the project runnable from the outer jar....
Hi
Just a quick question about the use of synchronized collection classes (like ArrayList or a Map wrapped in a synchronized Collections wrapper).

At the moment I am thinking about implementing the locking mechanism in the database code for the B&S project by using a synchronized block that gets the lock of an individual Contractor object - as follows:
(each Contractor object represents an entry in the database)


public long lock(int recNo) {

// Get the Contractor object from the ArrayList of Contractors (this list
// will be synchronized):
Contractor contractorToLock = contractorsList.get(recNo);

// Get the lock of this Contractor object:
synchronized (contractorToLock) {

// Main locking code here:

// Get the current thread
Thread thisThread = Thread.currentThread();

// Put this thread into a SortedMap called 'waiters', which maps
// Contractor objects (the keys) to accessing threads (the values).

waiters.put(contractorToLock, thisThread);

Finally use the SortedMap to check here to see if it is ok to write or modify the Contractor object. If the check does not succeed - wait().
The unlock() method will call notifyAll() to wake up the thread.

...

}

}
}

This is very simplified but the idea of using the 'waiters' SortedMap is to see which threads are accessing the Contractor object. Because it will keep the order of its elements, we can wait() until all 'writes' have gone through for example before we read.

The overall goal is to allow threads to lock on individual records, by checking the state of play in the SortedMap, rather than getting the lock to the entire contractorsList ArrayList for example.

So...
Is this threadsafe - given that the ArrayList and the SortedMap are synchronized?
Also - is it a good idea to lock on individual records at all? Would it be better to synchronize on :
1. the waiters HashMap,
then 2. the contractorsList ArrayList, then 3. the Contractor object itself when locking?
Even though this could be a bottleneck?

Hope this is clear