Hello,

What options are there of locking a persisted "object graph" on an application level (not DB) that would prevent people from accidently overwriting each others changes.

I have been thinking of a few options:

1. Use a manual "edit-request-lock" by saving the primary key of the entity in a separate table with an expire time. Drawback is of course if a person leaves the lock on others have to wait for it to expire.

2. Use a CVS like timestamp that have to match the one in the DB when writing back. Drawback is that you lose your changes if you lose the timestamp-battle.

3. A variation of 2. which is using reflection to merge the changes between the two versions and return a data structure indicating what has been changed. Could be a little hairy to implement with all special cases.

Anyone else wonder about this and come up with something?

2. is done by Hibernate via version or timestamp

t=0: user A "checks out" object X
t=1: user B "cheks out" object X
t=2: user A modifies object X
t=3: user B modifies object X
t=4: user A writes back object X
t=5: user B writer back object X (fails)

What would the natural way of using this feature so that user B
would not lose changes (s)he made? I assume an exception is thrown for B now when timestamp/versions are used?

It would of course be nice for user B to know that X is checked out but it doesn't help much because there is no way to know if user A is going to alter X or not...

StaleObjectException


I fight with my users not to want that ;-) there are lot's of drawbacks. The main one is duration of this lock in a disconnected env such as HTTP

Very true. But the collision can be very annoying too, especially if the model is very large and there is much information entered before it is persisted. One way would perhaps be a manual lock that could be enabled that would inform others that editing is being done, this probably only works if there overlappings are few and the environment is "friendly" and the editors know each other. The CVS merge style fix gets a little hairy when there are multi-row siblings...

Extremely interesting topic. Just want to share my experience.

What I have accomplished in the past is having a lockedby column for each object. If user wants to modify the object she will have to explicit set the lock on (well sort o,f since my interface will fill in name automatically whenever she pass through my write interface). If the object is currently locked by a user, other user will not be able to enter the modification screen. The lock can be cancelled by the user or admin, if the object has no lock on database or the user submit the write request doesn't equal the lock user then the write is rejected.

Again this is pessmistic lock and allows dirty read and with no database lock involved so it works well in HTTP environment. This is the only way to avoid heavy user change get lost. On the other hand if the changes are minor, db optimistic lock works well.

Just my 02c

Are you using some sort of expire time for the lock also? (i.e. two locking related fields per entity). Are you only locking the top of the object graph, assuming nobody else messes with the lower parts. OK, you can't force other software to respect your lock anyway.

Like I said, I have been experimenting with a static BeanMerger class that used in conjunction with a timestamp can take any two JavaBean standard-respecting object graphs and merge (overwrite) the changes using reflection, returning a data structure saying what has been changed. That way, the save scenario could (hopefully) be as follows:

t=5 user B writes back object X (fails)
t=6 system check for timestamp match
t=7 if match => write back object X
t=8 if no match check with user if do a clen reload graph from disk or
load&merge. User can review what has changed, if OK
t=9 user B writes back object X

Of course I must still check on the atomicity of the save action.

Runtime reflection for introspection of a full graph can be very CPU consuming. You have to be linked with Hibernate not to ckeck lazy object / collections. Sounds hard to do a generic proper comparator.

DB lockedby stuff is the solution I'd choose if I had to. I'd add an exipirationDate column not to keep eternal locks. This is a fully applicative stuff and will interfer with you business rules of save and update. Pretty messy after a while I guess.

Okay in my case the naviagation path is from top to bottom so a user can not lock the bottom if they have not hold the top lock. But again, I have extremely shallow object tree. Object are more linear. No, I don't have expiredate, it can be done easily but fire up a scheduler thread each time an object got lock it will start to scan the column. But I have an admin function which can unlock every row. Admin function basically rest the value. I thought of using timer thread to implement the lease stuff you are talking about. I just never get a chance to do it since reset value is so easy for the admin and so rare (usually after people editing done, they submit the page and the lock will be reset). Yeah, it deeply embeded into the bussiness stuff so you will see (if not locked then go ahead generate this editing link otherwise not generate link, only on HTTP layer though), but I suppose I can not find other better and cheaper solution than this.

Any thoughts on using a singleton class instance for check/lock/unlock instead of registering the information in the DB?

I don't like that. How about having several JVM instance ? Or even an admin ear and an application ear needing the same lock. Singleton is useless in those cases.