ciaran_cahill

Yes but won't you still have to extract the database file to use it, even if it is in the 'outer' jar?
For the first run of the program the user won't have the database file.

Wouldn't it be best to have a lock for the RandomAccessFile object and enforce a design rule that programmers must acquire this lock before using the object in any way?

Hi,
Maybe this has been asked already, but when you package the project for submission in the runme.jar, obviously you need to access the .db database file from the jar as opposed to directly from an ordinary file.

What is the best way to do this?
At the moment I am extracting the database file from the jar if it doesn't exist, and using this on subsequent runs.
The alternative would be to extract it and then write it back into the jar but I don't think this is a requirement. Or maybe this is incorrect?
Any ideas?
Thanks

Hi all
I'm doing the B&S assignment & was just wondering - what is the best way to deal with a client crashing while it is getting a lock on the database? Or for example, crashing just after it gets the lock and before it actually books or modifies a record?

The two main approaches I can see are :
a) Use an RMI callback to see if the client is still alive, if not then allow other threads to get the lock

b) Create a timer thread that will detect if a client has held a lock for too long (say for 30 seconds or more).

Or is it necessary at all to cater for this situation? It seems like something you could lose marks on if you don't check for it.

Thanks!

Hi
Any help with this would be much appreciated!!

In the B&S assignment I have an update() method in my database class (updating objects in the main ArrayList I use to hold Contractor details).

I use two ReentrantLocks - one for the main list of Contractor objects, and the other for the list of Contractor objects that are currently locked (to keep track of them). I am locking them both in the same order everywhere, and then unlocking them in the same order everywhere so as to avoid deadlock.

The thing is I don't need to actually modify the list of lockedContractors in this method. Just the main list of Contractor objects that the contractorLock is watching over.

Do I need to lock on the lockedContractors here anyway just to avoid deadlock??


contractorLock.lock();
lockedContractors.lock();

try {

... Do the work of modifying the Contractor here

}
catch (Exception e){
// nothing here yet - should be logged
}
finally {

lockedContractors.unlock();
contractorLock.unlock();
}


Thanks!