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".
