How about using a SELECT . . . FOR UPDATE statement to select the record being edited. Once you read the record it will be locked, and as long as you keep the transaction open for the duration of the edit then no other transaction will be able to select the same record for update. If the transaction times out the DB management system will release the record for someone else to work with.
Roland. -------------------------------------------------------------------------------- "If you stand up and be counted, from time to time you may get yourself knocked down. But remember this: A man flattened by an opponent can get up again. A man flattened by conformity stays down for good." - Thomas J. Watson, Jr. "Fred Janon" <[EMAIL PROTECTED]> wrote on 20/02/2007 10:44:20: > Interesting question! I don't have any experience in doing this but it made > me search in one of my Websphere book. Not sure if that would fulfill your > requirements but TRANSACTION_SERIALIZABLE and PessimisticUpdate-Exclusive > might be worth investigating. I am not sure what container you use and if > JTA is available to you. I would check the JDBC driver as well, it might > have some extra transaction support. Writing your own is probably pretty > tempting when the answer is not obvious and you would know how it works. On > the other side you have an extra write (at least) each time and need to > manage the lock if the transaction is abandoned. > > If you have the time to investigate more, you'll probably a transaction guru > soon. We, developers, have a tendency to avoid transactions and isolation > levels like plague... Not easy development and test subjects as the lack of > answers indicates... > > Good luck and let us know what solution you end up with, I am curious. > > Fred > > On 2/20/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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
