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?