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