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]
