This version number approach is often recommended over using a timestamp. I guess it has to do with computer clocks not being all that accurate.
> -----Original Message----- > From: Jacob Hookom [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 05, 2003 10:31 PM > To: 'Struts Users Mailing List' > Subject: RE: [OT] concurrent updates > > > Another alternative to time stamping is auto incrementing a field in the > row, so when you "check out" an object, you set a long value in > your object, > during an update, ask the DB for its current ID and if it's the > same or not. > > -Bocaj > > | -----Original Message----- > | From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Vic Cekvenich > | Sent: Wednesday, February 05, 2003 9:03 PM > | To: [EMAIL PROTECTED] > | Subject: Re: [OT] concurrent updates > | > | We not going any were.... but I am in a bad mood: > | - if you are using pessimistic locking, that means that you locked the > | row, no need for timestamp. > | - if you are using timestamp, then you are doing optimistic and > | protecting against dirty writes. > | > | .V > | > | Christopher Willingham wrote: > | > it's an answer. my personal opinion, using timestamps is the easiest > | and > | > fastest, having done both on many occasions. optimistic > style never was > | > acceptable unfortunately. > | > > | > ----- Original Message ----- > | > From: "Vic Cekvenich" <[EMAIL PROTECTED]> > | > To: <[EMAIL PROTECTED]> > | > Sent: Wednesday, February 05, 2003 9:39 PM > | > Subject: Re: [OT] concurrent updates > | > > | > > | > > | >>Hmmm .... > | >>Not sure if you are asking a question or answering an answer. > | >> > | >>- Locking a row or a leaf page the row is on on a large > system should be > | >>done only after careful consideration. Performance, Deadly embrace, > | >>other apps, user time out, dead sessions, etc. > | >> > | >>-Refresh of data has to do with row cache you do. Popular one is > | >>Poolman, where it needs to time out, but many others out there in use. > | >>Again, refresh is typically not done on large systems. > | >>(I think you are saying that when a DB changes a row, it should send a > | >>message to browsers and make it refresh the rows it's displaying and > | >>that you did this? OK if you say so.) > | >> > | >> > | >>If you are experienced SQL and know these topics well, then > you can make > | >>a choice. Else, if you are not intimate, I suggest optimistic cache > | >>approach with a decent cache decay. > | >> > | >>.V > | >> > | >>Christopher Willingham wrote: > | >> > | >>>when user A retrieves data also get a last updated timestamp from > | table. > | >>>When you go to update, use that in your where clause. If row not > | found, > | >>>someone else changed the row while user A went to get coffee. > | >> > | > Automatically > | > > | >>>refreshing with message in that event would be nice. > | >>> > | >>>- or - > | >>> > | >>>use a transaciton table to incorporate a checkout scheme, > ie, when user > | >> > | > goes > | > > | >>>to modify a customer, add transaction row to check customer out. > | Anyone > | >>>else attempting will find it already checked out and will be denied. > | >>> > | >>>I've done both in large systems > | >>> > | >>>----- Original Message ----- > | >>>From: "Vic Cekvenich" <[EMAIL PROTECTED]> > | >>>To: <[EMAIL PROTECTED]> > | >>>Sent: Wednesday, February 05, 2003 7:39 PM > | >>>Subject: Re: [OT] concurrent updates > | >>> > | >>> > | >>> > | >>> > | >>>>The answer is... what do you want it to be? > | >>>> > | >>>> > | >>>>I You dao updates via reflection does update via the primary key. > | >>>>Last one wins. > | >>>>or > | >>>>II You dao updates via reflection for all the changed fields. > | >>>>Both could win or 2nd one fails. > | >>>>or > | >>>>III Your dao update via reflection for all the fields or via > | data/time. > | >>>>It fails always if any changes. > | >>>> > | >>>>If you did not understand this, just use choice I. This has > nothing to > | >>>>do with patterns, and everything to do with SQL. > | >>>> > | >>>>.V > | >>>> > | >>>> > | >>>> > | >>>>[EMAIL PROTECTED] wrote: > | >>>> > | >>>> > | >>>>>pls excuse my struts-[OT] question, but I would appreciate to learn > | how > | >>>> > | >>>you > | >>> > | >>> > | >>>>>handle the situation of concurrent data update within your web > | >>>>>applications. > | >>>>> > | >>>>>think about the following situation: > | >>>>>1. user A fetches customer 007 and displays 007 within his browser > | >>>>>2. user B fetches customer 007 as well and displays 007 within his > | >>>> > | >>>browser > | >>> > | >>> > | >>>>>3. user A updates customer 007 > | >>>>>4. user B updates customer 007 as well... > | >>>>> > | >>>>>How do your systems react? > | >>>>>a) the last update wins? > | >>>>>b) trying to merge updates of user A and B? > | >>>>>c) sending a message to user B that customer 007 was changed since > | >>>> > | >>>loading, > | >>> > | >>> > | >>>>>and that user B has to re-enter his update > | >>>>>or d) do you have a locking mechanism which prevents this > situation - > | > > | >>>> > | >>>user > | >>> > | >>> > | >>>>>B has no "update" button if customer 007 is already in somebody > | else's > | >>>>>update screen > | >>>>>or e) ??? > | >>>>> > | >>>>>thanks for sharing your solutions to this common problem > | >>>>>rene > | >>>> > | >>>> > | >>>> > | > >>>>--------------------------------------------------------------------- > | >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > | >>>>For additional commands, e-mail: [EMAIL PROTECTED] > | >>>> > | >>>> > | >>> > | >> > | >> > | >>--------------------------------------------------------------------- > | >>To unsubscribe, e-mail: [EMAIL PROTECTED] > | >>For additional commands, e-mail: [EMAIL PROTECTED] > | >> > | >> > | > > | > | > | > | --------------------------------------------------------------------- > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
