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