Before updating we fire a "select for update (no wait)" to retrieve the
current value of RecordIdent
----- Original Message -----
From: "Ted Neward" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 17, 2002 3:07 AM
Subject: Re: good technique for table row locking
> How do you ensure that two entities don't obtain the "next" RecordIdent
> simultaneously?
>
> Ted Neward
> {.NET || Java} Course Author & Instructor, DevelopMentor
> (http://www.develop.com)
> http://www.javageeks.com/tneward
>
> ----- Original Message -----
> From: "Andreas Maschke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 16, 2002 3:42 PM
> Subject: Re: [EJB-INT] good technique for table row locking
>
>
> > I think this approach is too simple to solve "real word problems". Users
> > always make mistakes. And they make all of them ;-).
> > Good software must help to avoid such mistakes. (Or would you like an
IDE
> > which says "This file was modified by another user. You are stupid.
Please
> > reboot and think it over." I would prefer a message like "This file was
> > modified by another user. Do you want to reload it?")
> >
> > In our application we use an integer field "RecordIdent" (instead of a
> > timestamp) to lock records.
> > This value is incremented each time the record is updated. Before
updating
> > the value is checked against the current value in the database.
> > If they doesn't match an error message is displayed.
> >
> > ----- Original Message -----
> > From: "Craig McMurtry" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 16, 2002 6:31 PM
> > Subject: Re: good technique for table row locking
> >
> >
> > > There is an option that does not require ever (1) locking a record (2)
> > > notifying users. Simply program the application so that when users
> update
> > > records, only the fields that they actually modified are changed: the
> > > remainder are left as they are at the time of the update. Apparent
> > > collisions will occur if two users read a record before either of them
> > > updates it, they both modify the same field, and they both update the
> > > record. In that case, the change to the field that is made by the
user
> > who
> > > updates the record last will overwrite the other user's change without
> > > either user being aware that occurred. However, this case will only
> arise
> > > in practice if there is some error in the manual system into which the
> > > automated system is incorporated. Two users should never intend to
> update
> > > the same field with different values simultaneously except in error.
> > > Efforts to make the automated system identify that error in the manual
> > > system will inevitably be both unsatisfactory and more expensive than
> > > beneficial.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Ted Neward
> > > <tneward@JAVAGEEK To:
> > [EMAIL PROTECTED]
> > > S.COM> cc:
> > > Sent by: A Subject: Re: good
> > technique for table row locking
> > > mailing list for
> > > Enterprise
> > > JavaBeans
> > > development
> > > <EJB-INTEREST@JAV
> > > A.SUN.COM>
> > >
> > >
> > > 01/16/2002 12:31
> > > AM
> > > Please respond to
> > > Ted Neward
> > >
> > >
> > >
> > >
> > >
> > >
> > > I mean, rather than hold the lock across user invocations, do a SELECT
> and
> > > pull back all the columnar data including a column that holds the
> > timestamp
> > > of the last time this row was modified. Do your user interaction, then
> as
> > > the user presses "Confirm/Update/Submit/Go", do another SELECT...FOR
> > UPDATE
> > > and check the timestamp in the column again. If they match (the
original
> > > and
> > > the recently-retrieved), then nobody touched your row and you can
> > continue;
> > > if they don't match, somebody updated the row out from underneath you
> and
> > > you have to notify the user.
> > >
> > > Ted Neward
> > > {.NET || Java} Course Author & Instructor, DevelopMentor
> > > (http://www.develop.com)
> > > http://www.javageeks.com/tneward
> > >
> > > ----- Original Message -----
> > > From: "bakka" <[EMAIL PROTECTED]>
> > > To: "Ted Neward" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Thursday, November 15, 2001 9:02 PM
> > > Subject: Re: Re: good technique for table row locking
> > >
> > >
> > > > Ted, what do you mean by locally held timestamp.
> > > > If you wnat to know the latest timestamp, you have query again to
the
> > > > database, just before update.
> > > >
> > > > ebreddy
> > > > ----- Original Message -----
> > > > From: "Ted Neward" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, January 10, 2002 12:30 PM
> > > > Subject: Re: good technique for table row locking
> > > >
> > > >
> > > > > > Has anyone else tried to do something like this? Any
> > > > > > thoughts on overcoming these issues?
> > > > > >
> > > > > Don't use EJB.
> > > > >
> > > > > Since you've already got the model in mind you're trying to do,
why
> > not
> > > > just
> > > > > write the raw SQL from JDBC and be done with it?
> > > > >
> > > > > Beware, though, that this kind of stateful locking logic is really
> > easy
> > > to
> > > > > get wrong, and leave rows locked indefinitely. What usually works
> > > better
> > > > is
> > > > > to place a timestamp column on each table containing the last time
> > this
> > > > data
> > > > > was modified (and make sure each UPDATE or INSERT also puts the
> > current
> > > > time
> > > > > into the column). While the user works with the data, on each
> > > subsequent
> > > > > action, compare the locally-held timestamp with the one retrieved
> from
> > > the
> > > > > database on each fetch, and if they differ, somebody obviously
> screwed
> > > > with
> > > > > the row--alert the user, decide what to do from there.
> > > > >
> > > > > Contention is the enemy of scalability. Locks introduce
contention.
> > > Ergo,
> > > > > reduce locks if you want to scale.
> > > > >
> > > > > Ted Neward
> > > > > {.NET || Java} Course Author & Instructor, DevelopMentor
> > > > > (http://www.develop.com)
> > > > > http://www.javageeks.com/tneward
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Michael Remijan" <[EMAIL PROTECTED]>
> > > > > To: <[EMAIL PROTECTED]>
> > > > > Sent: Saturday, January 05, 2002 7:31 AM
> > > > > Subject: [EJB-INT] good technique for table row locking
> > > > >
> > > > >
> > > > > > Hi group,
> > > > > >
> > > > > > I'd like to effectively do a "select ... for update"
> > > > > > SQL query so that other's can't mess around with those
> > > > > > rows while I have them. Although this is easy to do,
> > > > > > the problem I'm having implementing this with J2EE is
> > > > > > dealing with UserTransaction. Specifically, my
> > > > > > problems are:
> > > > > >
> > > > > > (1)
> > > > > > a UserTransaction doesn't "refresh" itself like an
> > > > > > HTTP session object does, so it always times out.
> > > > > >
> > > > > > (2)
> > > > > > There is no listener or callback method I can use for
> > > > > > user defined transactions that will alert the bean
> > > > > > when the transaction has timed out.
> > > > > >
> > > > > > (3)
> > > > > > When the transaction does time out, it's status is
> > > > > > changed to marked for rollback but doesn't actually do
> > > > > > the rollback.
> > > > > >
> > > > > > Has anyone else tried to do something like this? Any
> > > > > > thoughts on overcoming these issues?
> > > > > >
> > > > > > Thanks in advance,
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > >
> > > > > > __________________________________________________
> > > > > > Do You Yahoo!?
> > > > > > Send FREE video emails in Yahoo! Mail!
> > > > > > http://promo.yahoo.com/videomail/
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
===========================================================================
> > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
in
> > > the
> > >
> > > > > body
> > > > > > of the message "signoff EJB-INTEREST". For general help, send
> email
> > > to
> > > > > > [EMAIL PROTECTED] and include in the body of the message
> "help".
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
===========================================================================
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> the
> > > > body
> > > > > of the message "signoff EJB-INTEREST". For general help, send
email
> > to
> > > > > [EMAIL PROTECTED] and include in the body of the message
"help".
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email
to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > The information transmitted is intended only for the person or entity
to
> > > which it is addressed and may contain confidential and/or privileged
> > > material. Any review, retransmission, dissemination or other use of,
or
> > > taking of any action in reliance upon, this information by persons or
> > > entities other than the intended recipient is prohibited. If you
> > received
> > > this in error, please contact the sender and delete the material from
> any
> > > computer.
> > >
> > >
> >
>
===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email
to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> >
> >
>
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
