Leaving a database connection open for that period of time (possibly minutes/hours) isn't advisable from what I understand.
On 2/19/07, Fred Janon <[EMAIL PROTECTED]> wrote:
Yep, SELECT for UPDATE is what's behind TRANSACTION_SERIALIZABLE... On 2/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
