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