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