Nicolas Williams wrote:
On Wed, Dec 06, 2006 at 10:04:42AM -0600, John Stanton wrote:
hongdong wrote:
I just have a base question:
assume user A and user B now both connection to a same database and both of
them want to update a same record,but only one is allowed
in this condition:
A begin to browse the data in a client application,and load rowid into GUI
and keep it in memory.
B update the record which A want to update
A now used the id stored in memory to update the same record
now it's wrong.
anyone can give me advice how to avoid this and keep the operation is
effient
thanks!
Use a transaction. That is why they are implemented.
I think you misunderstood the poster.
'A' wants to read some rows, end its transaction and, some time later
(minutes, hours, day), when the user manipulates the row through the
GUI, update that row.
'A' can't keep the database locked for arbitrary periods of time, and
'B' needs to write independently of 'A'.
Transactions don't help 'A' in this case.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
I fully understood. It is an age old problem that has puzzled
generations of system designers. My first exposure was over thirty
years ago. The approach we discovered worked was to treat it as a
transaction in the logical sense. The decision then becomes one of
granularity because obviously you cannot keep the whole DB locked to
handle one item if you have multiple users.
Logic using a committed journal and an application implemented rollback
and commit can effectively implement the transaction in a multiple user
environment.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
