Originally posted by Musab Al-Rawi:
but i think that those lock and unlock can be done by calling the lock() and unlock() in DBMain, that's the provided interface.
I know that many ranchers specified extra requirement, that record which is uptated/deleted should be locked first and are probably avoiding problem I described
Originally posted by Jar Jaquiso:
I think you're being to strict on the requirements.
Originally posted by Mark Ebeling:
I don't know if this helps, but I put in a LockManager similar to what Andrew shows in his book (pg. 158). Then I only allow access to the delete method in my Data class as follows:
This way you can only delete if you have locked the record first, and have the actual key. The LockManger just decouples the locking from the data access. You either have the correct lock or not. I will definitely define all my conclusions in my choices.txt, but I think this is how others have coded and passed.
Originally posted by John Stone:
It is not very likely, that Sun will test for this, I'm just saying, that it is possible to exploit that implementation.
How two threads can have same cookie?
They share it.
Thread 1 locks record and receives cookie, after this operation it stores cookie in place where everybody else can read it. (This could be done in many ways)
Or the thread 1 can just spawn 3 more (or 15) new threads and 'give' just received cookie to them. (e.g. as a parameter in constructor)
I know, that you are not implementing it this way, but you never know what kind of tests Sun prepared, perhaps they are also testing for this, but it doesn't reflect on your score, because too many rancher had 80/80 from locking with your approach.