Just out of curiosity, can you tell more about your use case? I just have a hard time believing you'd need something like this for all of your tables - rather I'd assume it's something specific to a type of a record. And if it's the latter, I'd just implement it in the application level along the lines you'd suggested. But I'm not sure I'd call it locking, which I understand as a database feature for enforcing atomic transactions. It'd be fairly easy to implement the checking and enforcing of your edit rule in a Hibernate Interceptor. For obtaining the application level "lock" you can use optimistic locking; this is sort of the same as doing svn lock.
Kalle On 2/19/07, Murray Collingwood <[EMAIL PROTECTED]> wrote:
James Carman <james <at> carmanconsulting.com> writes: > You can use optimistic locking. When the user submits and they have > outdated data, then you just merge the object's data with what is in > the data store and show it back to the user for them to confirm it. In an application where the user can spend 20 minutes completing the information in a row, they are not going to be happy when they find out somebody else has been updating this same row and the information has all been merged. They then spend another 10 minutes cleaning up all of the duplicated changes. Even pessimistic locking is not sufficient. I need guaranteed write-exclusive locking for the duration of the request. ie when I read-for-update the record should be locked against all other read-for-update requests until I save my changes and release the lock. It sounds as though I'm going to have to write my own...again. Cheers mc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
