How to prevent a user from deleting a record while another is edi ting it 2004-09-29 - By Yongqin Xu
Back
Of course if you are not using J2EE, you have to deal
with it youlself. From design point of view, you don't
want to leave long transaction stay open for long,
besides concurrency issue, you will also kill your
scalabilty.
Using timestamp and lock field will not completely
solve race problem. What if two user try to access
timestamp or lock field at the same time?
Since when you are using java.sql.Connection which let
you specify your isolation level, use it even not in
j2ee environment, why not?
--- Stefan Frank <s.frank@(protected)> wrote:
-- ---- ---- ---- ---- ---- -----
Unfortunately, this is nothing where j2ee helps.
Of course, thecontainer can deal with concurrent
transactions and handletransaction-isolation. But if
you look at the simple use-case, wherepeople open an
edit-form, go to dinner, come back and submit
updates,you will see, that there is no technical,
general solution with thesevery-very-long-running
transactions going over half an hour or longer.How you
deal with these form of "concurrency" is not a
j2ee-issue, butan issue of the application-logic.
To my knowledge, most people are using either (a)
thetimestamp-approach(give a timestamp of the latest
change to yourclient, and only allow an update, if the
timestamp hasn't changed inthe meantime) or (b) the
token-approach(have an extraopenForEdit-method, that
gives the client a token, and only the userwho has the
token can update the Entity, if other users
callopenForEdit they raise an exception).
There is not so much code to write for a), and it
works nicely when theconcurrent updates are unlikely -
if they happen often, you somehowhave 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 (whathappens if a client
breaks and is not able to resubmit the token, breakthe
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 tostandardize on this...
cheers
stf
Yongqin Xu wrote:
As J2EE promised, why we still have to deal withlow
level transaction synchornization issues likethis. The
container with CMP will take care of thisthrough
transaction isolation levels (those staticfinal
integer in java.sql.Connection). Do not reinventthe
wheel and waste your time here.--- "Gupta, Rajan"
<Rajan.Gupta@(protected)> wrote:
The solution described by Nicholas is what I
haveimplemented. I have abeingLockedBy field which
holds the userid of therecord who is currentlyediting
the record. My question is what in CMP willprevent two
usersupdating the record at the same time? Let us
assumethat in a clusterenvironment, two users access
the record at the sametime, what type oflocking one
can use to prevent simultaneous update.EJB 2.0 does
not haveFOR UPDATE (besides this is evil
anyway).-- --Original Message-- --From: An interest
list for Sun Java Center
J2EE===================================================================
=Companion
Site: http://www.corej2eepatterns.comJ2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatternsList
Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.htmlUnsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
=====
'Focused action beats intellectual brilliance every time in the market place of
human affairs' --Mark Sanborn
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Yongqin Xu
Senior Software Engineer
Level 3 Communications Inc.
* Oracle9i Certified Database Administrator
* Sun Certified Enterprise Architect in J2EE
* Sun Certified Web Component Developer
* Sun Certified Java2 Developer
* Sun Certified Java2 Programmer
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
__ ____ ____ ____ ____ ____ ___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
====================================================================
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@(protected)
|
|
