I would liek to post my code here but dont think its allowed. So far i have provided read and lock from conCurrentLock class and have provided readLocks whenever I read from the database and write locks when I write to the database in my persistContractor method.
Now whats with this lock cookie? Am I supposed to use it? And how do I generate a sufficient lockCookie? The only thing I can think of is that this lockCookie can be used on a synchronize block when i call on a delete/update. Am i close?
SCJP 6.0, SCJD (400/400), SCBCD for JEE 5, SCWCD 1.4 I do videos for development at
I am probably the only developer ever to have had an orange sized brain tumor in my brain while learning development!!
If you have it (the cookie), you better use it! Mine goes something like this. Lock() calls generateCookie(long recNo) which sends the cookie back to lock, so forth and so on. You generate the cookie with the record number and most use a Random with one of the Time classes. Do a search on lock cookie and you will find lots of thoughts on this.
The lock cookie is to be used when multiple network clients has concurrent access for the SAME record in update or delete operations.
So you need to use a lock cookie each time a network client want to update or delete a record.
Yeah I now how to generate one but I am at a loss for how to use the lock cookie?
Joined: Aug 29, 2005
You use it to uniquely identify the client. This is actually easier than not having one. Generate it in, or from lock(), pass it back in from unlock(). If it isn't found in the Map or Set of locks, throw SecurityException. I put the recNo and the cookie in a HashMap called locks.
Anne Crace wrote:This is actually easier than not having one.
You are so right! My given interface does not have one
why you need lock and unlock is described perfectly in the scjdfaq
Why such a lockCookie exists? very easy: when a record is locked, you generate a cookie. only a record can be updated/deleted when that same cookie-value is provided (so you have to store them with the record number). same for unlock. so you are sure that 1 client can change the record at a time. if another client tries to update the same record (it doesn't know the actual cookie value, so it will be a guess), this client will not be able to update the record and will receive a security-exception instead
Ok here is why I am confused. I thaught it was possible to just implement a the java Concurrent lock class and enable ReadLock when reading from the database and writeLock when writing to the database. I have a read() that reads a record according to the file location. This is my only access to reading records from the database and appon entering this method a readLock.lock() is called and released in a final block before the method completes. A similiar function is provided when I write to the database. Only 1 method provides reading and likewize upon entering this method you enter a try block where a call to writeLock.lock is made and released when the method completes. Is this not good enough for locking?
First you have to synchronize the access to your db-file to not corrupt that file. an example would be: client1 (thread 1) wants to update record 1 and client2 (thread 2) wants to update record 2.
to write a record you have something like:
now if after line 1 thread 2 gets cpu it changes the filepointer and write the bytes. then thread 1 gets the cpu and the file pointer will point to another record than record 1, resulting in updating another record or making your data file corrupt. And that's not something you want, so to ensure correct behavior you must protect/synchronize access to your data file. you can do it by synchronizing on the file, using the java concurrent classes, synchronizing the complete methods,...
Secondly you have to take care of this situation (from the scjd-faq):
So having somehow synchronized the access to the file, we still have a problem of two clients believing that a record is available, and both trying to update it. That is:
- Client A checks that record 5 is available
- Client B checks that record 5 is available
- Client A updates record 5 with their client number
- Client B updates record 5 with their client number
now client B has overwritten client A's booking
That's the reason why you have a lock/unlock method in the interface. if client1 locks record 5, only client1 is able to update/delete this record. After client1 unlocks the record, it's back available to other records for being updated/deleted (but they have first to acquire the lock on that record).
Thank you for reply. I have synched my record accessing. My problem was this. I put all the implement DB methods into my file accessing class and I therefore confused myself. I forgot that update/delete declare the lock exception in Data.java and therefore have to declare it in my data accessor class too. This lead me to believe that the exception must originate from my accessor class()this is where i confused myself. But I forgot that this could originate in a lockmanager class and would be irrelevant to my method sig as it would needed to be declared as capable of throwing an exception throughout my program :P