Re: [OT] concurrent updates

[Vic Cekvenich]

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]