This is what TopLink uses for optimistitic locking. Just don't forget to update the timestamp in the update. --Angus
> -----Original Message----- > From: Jean-Louis [mailto:[EMAIL PROTECTED] > Sent: Monday, November 03, 2003 4:43 AM > To: Tomcat Users List > Subject: Re: Design advice needed. > > > Hi, > > you can use a timestamp and write for example : > update ... > where ... > and timestamp = 'the timestamp read by the select statement > and saved in your application' > > And then check the number of rows updated. > > Antony Paul a écrit : > > > Can u pls mention what is that Oracle feature ?. Reading > the data again is > > time consuming. > > ----- Original Message ----- > > From: "Johan Kok" <[EMAIL PROTECTED]> > > To: "'Tomcat Users List'" <[EMAIL PROTECTED]> > > Sent: Monday, November 03, 2003 12:17 PM > > Subject: RE: Design advice needed. > > > > > Anthony, > > > > > > Did you consider reading the record without locks, and > when an updated are > > > made, to take a write-lock, check that the original > record are still the > > > same and then apply, otherwise fail. > > > > > > Your intentions might not work unless all writes are > passed through the > > > container, as Oracle will not have any control, until a > write occurs, i.e. > > > you will have to open with read only, and only take out a > lock when you > > are > > > going to write, as described above. for safety sake your > container will > > have > > > to re-read the data in any case, before commiting, > otherwise it may update > > > changed data, e.g. updates that are made through other > processes or even > > > triggers. > > > > > > If my memory serves me right, that is something you can > do easily with > > > Oracle (i.e. there's a standard feature implemented), > even with Oracle > > 6/7. > > Jean-Louis CLAUSS > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
