You will have to implement some sort of record locking scheme. If you use
EJB, you can implement Transactions. Otherwise, you have to code it.
There are three approaches: Truly Optimistic, Optimistic, and Pessimistic.
For Truly Optimistic, you basically just hope only one resource is changing
the record at the same time. It seems that a lot of systems rely on this.
In the Pessimistic model, you lock the record the whole time one resource
(i.e. user) is changing the record. This model suffers from the scenario
where a user brings up a record in change mode, then goes to lunch.
I think the Optimistic model is best. Here is a section from a design
document I wrote (reference article -- Object Concurrency Control 101,
Software Development, Jan. 2001 (http://www.sdmagazine.com/) ):
Optimistic Record Locking
This application will use the Optimistic Record Locking Model to handle
data collisions. A data collision happens when two or more users attempt to
update the same record. The optimistic concurrency control approach is
scalable, because it does not make other pieces of the system wait for the
lock to release.
Detailed Approach
When a user specifies a record to be modified, it is read from the
database. Each record will contain a revision number (a simple incremental
counter). The user manipulates it as necessary. When the changes are
applied, the source is briefly locked and the revision number is checked to
see if it is unchanged at the point of update. Then changes are committed
and the record is unlocked. When a program discovers that the revision
number on the source has been updated-indicating that another copy of the
source has since written it-we say that a collision has occurred. Since
it's unlikely that separate users will access the same object
simultaneously, it's better to handle the occasional collision than to limit
the size of the system.
Although a timestamp can be used instead of a revision counter, there
are problems associated with this approach. If two servers are used it's
possible that they can each generate the same value (regardless of whether
their internal clocks are synchronized). If you want the copies to assign
the mark value, and you want to use time stamps, then you must add a unique
ID for the server, such as its serial number.
Handling Collisions
If multiple people are changing a copy of the same record, the first
person to write the change back will be successful. All others who obtained
the record while the first person was modifying it will not be able to
update their change. They will receive an error message informing them that
their update was unsuccessful. Collisions should be rare on a system of
this size.
Date: Tue, 13 Mar 2001 18:38:35 +0530
From: sharma Sumeet <[EMAIL PROTECTED]>
Subject: How does one manage concurrency issues with JDBC?
MIME-Version: 1.0
Content-Type: text/plain
hi All
How does one manage concurrency issues with JDBC? I wna avoid locks
on the
tables.
Thanks & Regards
Sumeet
. . . . . . . . . . . . . . . .
Dave Whaley
Developer, Web Applications
Robert Half International, Inc.
(925) 598-5256
. . . . . . . . . . . . . . . .
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
