Very good question on a very difficult topic. This is one of the hardest
things in a transactional application. The a-d choices you listed are all
possibilities and the one you select depends on your situation/requirements.
What does the customer want to happen in this case? This topic is
I guess your choices are:
1. last one wins.
2. Check last modified time in each row before commiting changes. so you have a
select before update.
there could be more..
anil
Jerome Jacobsen wrote:
Very good question on a very difficult topic. This is one of the hardest
things in a
By default the last update would win. Ok for small systems.
Any system with multiple editors should at the very least have some auditing
columns (in the data table or a separate table) like 'creator', 'modifier',
etc. The most common solution to concurrent updates is a 'lockedBy' column,
to
]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Subject: Re: [OT] concurrent updates
Date: Wed, 05 Feb 2003 08:25:14 -0600
I guess your choices are:
1. last one wins.
2. Check last modified time in each row before commiting changes. so you
have
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.
I have to live with a traditional telnet app which is also updating the
files, and I can't hold record locks from the web, so... I read in
thanks everybody for your feedback
I will have a look into the lockedBy column mentioned by Carlos and propably
I'll add a column lockedTS (timestamp) and set the validity of the lock to a
similar time frame as the session timeout
-Original Message-
From: [EMAIL PROTECTED]
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
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
, 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
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
: 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
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
, February 05, 2003 10:02 PM
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
13 matches
Mail list logo
