Unfortunately, this is nothing where j2ee helps. Of course, the
container can deal with concurrent transactions and handle
transaction-isolation. But if you look at the simple use-case, where
people open an edit-form, go to dinner, come back and submit updates,
you will see, that there is no technical, general solution with these
very-very-long-running transactions going over half an hour or longer.
How you deal with these form of "concurrency" is not a j2ee-issue, but
an issue of the application-logic.
To my knowledge, most people are using either (a) the
timestamp-approach(give a timestamp of the latest change to your
client, and only allow an update, if the timestamp hasn't changed in
the meantime) or (b) the token-approach(have an extra
openForEdit-method, that gives the client a token, and only the user
who has the token can update the Entity, if other users call
openForEdit they raise an exception).
There is not so much code to write for a), and it works nicely when the
concurrent updates are unlikely - if they happen often, you somehow
have to deal with changes that where made by the second committer,
which may become a hairy issue.
b) takes some more code, but is safer, and allows only one person to
"check-out" the entity. But you still have to deal with timeouts (what
happens if a client breaks and is not able to resubmit the token, break
the lock or note the locks owner and allow re-submission etc.)
anyway, there are so many choices to make on how to deal with this,
that you cannot realistically hope to have any sort of middleware to
standardize on this...
cheers
stf
Yongqin Xu wrote:
As J2EE promised, why we still have to deal with
low level transaction synchornization issues like
this. The container with CMP will take care of this
through transaction isolation levels (those static
final integer in java.sql.Connection). Do not reinvent
the wheel and waste your time here.
--- "Gupta, Rajan" <Rajan.Gupta@ACS-INC.COM> wrote:
The solution described by Nicholas is what I have
implemented. I have a
beingLockedBy field which holds the userid of the
record who is currently
editing the record. My question is what in CMP will
prevent two users
updating the record at the same time? Let us assume
that in a cluster
environment, two users access the record at the same
time, what type of
locking one can use to prevent simultaneous update.
EJB 2.0 does not have
FOR UPDATE (besides this is evil anyway).
-----Original Message-----
From: An interest list for Sun Java Center J2EE
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com
