Locking strategy and thread safety - similar but not the same?
Eamonn O'Connell
Greenhorn
Posts: 11
posted 10 years ago
Hi All,
I've read many of the threading related (ahem) threads, which have really helped me consider angles I had previously overlooked. One such angle I'm mulling over is the relationship between the locking strategy (as defined in the provided interface) and the requirement that the application be thread safe. Are they the same, or just similar?
My own view on this is that they only similar. The locking methods in the provided interface are offered almost out of convienence to the caller. The other methods (create, update, find, etc.) should be thread safe with out the help of lock, unlock, and isLocked. The locking methods are there to ensure that the following situation does not occur:
2 clients and 1 db/server
Both clients wish to book the same unbooked record
They both execute the booking almost at the same time.
The locking methods ensure that no double booking occurs.
I think this ties in with the argument about whether to expose the locking fuctionality to the client. Of course there is no right answer, but I think the locking functionality/responsibility should be propagated up to the client rather than say employing the adapter pattern at the db level.
Anyone hava any thoughts on this?
I've read many of the threading related (ahem) threads, which have really helped me consider angles I had previously overlooked. One such angle I'm mulling over is the relationship between the locking strategy (as defined in the provided interface) and the requirement that the application be thread safe. Are they the same, or just similar?
My own view on this is that they only similar. The locking methods in the provided interface are offered almost out of convienence to the caller. The other methods (create, update, find, etc.) should be thread safe with out the help of lock, unlock, and isLocked. The locking methods are there to ensure that the following situation does not occur:
2 clients and 1 db/server
Both clients wish to book the same unbooked record
They both execute the booking almost at the same time.
The locking methods ensure that no double booking occurs.
I think this ties in with the argument about whether to expose the locking fuctionality to the client. Of course there is no right answer, but I think the locking functionality/responsibility should be propagated up to the client rather than say employing the adapter pattern at the db level.
Anyone hava any thoughts on this?
posted 10 years ago
Hi,
Your assumption is correct.
With the locking mechanism you guarantee that only one client at a time can update or delete a record.
Suppose two clients want to delete record 4 for example.
Client A locks record 4 (suppose he gets first CPU).
Client B wants to lock record 4 but being locked by Client A it is forced to wait.
Client A deletes record 4 and then releases the lock.
At this time client B could gain the lock on record 4 but since it is already deleted he will only get a RecordNotFoundException.
Andrew explained this several times on this forum. I hope that I understood it correctly.
Regards,
Romeo
Your assumption is correct.
With the locking mechanism you guarantee that only one client at a time can update or delete a record.
Suppose two clients want to delete record 4 for example.
Client A locks record 4 (suppose he gets first CPU).
Client B wants to lock record 4 but being locked by Client A it is forced to wait.
Client A deletes record 4 and then releases the lock.
At this time client B could gain the lock on record 4 but since it is already deleted he will only get a RecordNotFoundException.
Andrew explained this several times on this forum. I hope that I understood it correctly.
Regards,
Romeo
SCJP 1.4, SCJD, OCE EJBD 6
