How to prevent a user from deleting a record while another is edi ting it 2004-09-28 - By Gerard Toonstra
Back
Although the timestamp approach is somehow valid, I think the requirement
is very strange. The requirement to me re-reads as:
"Normally we would allow a user to delete the data, *except* when someone
else is just about to modify it."
That doesn't really make sense to me. What makes more sense to me is:
"When you are editing data that someone else has deleted in the meantime,
the application will return an error."
How many seconds should elapse after the timestamp before the record
*may* be deleted by someone else? It is possible that someone starts to modify
the data, then goes on doing something completely different. Person B then
cannot delete the data until X minutes expire and this original requirement
thereby causes more frustration then it does good. Does this time need to be
configurable as well??? ..... ->>
The cause is that something recording the start of a particular transaction is
not as volatile as the transaction itself and is fully detached from that
transaction.
I would solve this requirement differently, but it requires more effort:
1. Do a lookup of the data.
2. Present the data to the user. Are you sure you want to delete the data
as you
see it on screen?
3. If yes, record a delete request in a table, together with a version
identifier of
the data "as it is seen". ( use timestamp here? ).
4. Delete the data X hours later from a batch process, when no intermediate
updates
have occurred ( timestamp > recorded version timestamp ).
If the data is then *actually* modified before these X hours, the data will
not be deleted.
Otherwise it goes to the trashbin. Having said all this, it's definitely
preferable
to do something simpler or not anything at all :)
The simplest approach is for the modify action to delete all outstanding delete
requests as it updates data. No timestamp is then needed.
Just record when the delete request is created for the batch process 24
hours later.
About the modification process:
I haven't seen other responses as I am new to the list, but I think in any
case,
the "old" data is needed by the update operation.
There are possibly several approaches from there, like:
1. Lock the row in question you wish to update.
2. Select the data again as it is now just before the update.
3. Verify it's the same as what you have in the old data object.
4. Perform the update, set data to "new".
5. Commit.
or update the row directly:
UPDATE A SET X = <new> where Y = <key> and X = <old> ( and.... z.current =
z.old .... )
If no updates have occurred, apparently it has been edited inbetween the
old retrieval and
the new update. The update result will then returns 0 rows updated.
The user will then normally be sent back to the beginning and has to do
everything again.
Only rarely do I see applications where the new data is shown and a
confirmation is requested
whether the user really wants to overwrite the new current date with the
new data previously entered.
Just 2c,
Gerard
At 02:21 28/9/2004, you wrote:
>Hi,
>Another is editing means somebody is using the modify / update page.
>SO, u can insert a timestamp in the table when ever u use this table in
>modify mode.
>Whenever u select the data frm this table get this timestamp also. Then when
>u need to update the DB only if the selected and the current timestamp in
>that column is equal.
>
>Otherwise what u r doing is updating the data which is not the correct
>version which u wanna to be.
>
>This is called Version Control pattern.
>
>Regards,
>Manish
>
>
>-- --Original Message-- --
>From: An interest list for Sun Java Center J2EE Pattern Catalog
>[mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Gupta, Rajan
>Sent: Sunday, September 05, 2004 9:49 AM
>To: J2EEPATTERNS-INTEREST@(protected)
>Subject: How to prevent a user from deleting a record while another is
>edi ting it
>
>
>I am looking for a pattern for CMP based persistence model under EJB 2.0
>which will prevent a user to delete a record while another is editing it.
>
>Thanks in advance,
>Rajan
====================================================================
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)
|
|
