These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: problem related to concurrency
PostPosted: Wed May 17, 2006 1:27 am 
Beginner
Beginner

Joined: Tue Feb 28, 2006 3:16 am
Posts: 28
NH version 1.0.2

This problem is related to concurrency, concurrent users are accessing the application and making change. Application contains a tree component which has nodes, subnodes, leafs etc. Constraint is u can not add duplicate node or subnode or leafs.
Now i m storing all this structure in a object tree, this means when i save the data i store only the rootnode because it contains all the hierarchy of objects.
It may happen that some nodes are added , some are modified , some are deleted in this tree.
In this situation I need to implement the concurrency. Here are some of the scenarios for that.

1> User A, User B loads the tree component, user A created nodeA somewhere in the the tree and save it, after some time UserB created the node with the same name at the time of creation of that node on UI it validates that no such node exists but in the mean time UserA saves node with the same name.
2> userB has done some more changes and now saving, since nodeA is already created by UserA it should ask for concurrency conflict.
3> As i already say i m not saving a single record in the database through Nhibernate (otherwise i could have test it at the time of saving) , but its basically object tree (may contains multiple records with various operations on them)
4> Lastly i dontnot to add any version related column in my databases tables .


Can somebody plz tell me how can i implement the concurrency in this case


I can specify the following scenarieos and my understanding about that.
Is there any way that i dont use the version, if version is mandatory for concurrency how it will address the following scenarios



1> UserA Added new node saves the node , user B created the node with the same name tries to save
NH Solution : Here we can not use the version since there is no persistent state initially

2> UserA modified the node saves it then userB modified the node
NH Solution: this can be handled by the version

3> UserA deleted the node, saves it now userB trying to delete the same node
NH Solution: We can not use version because not persited state is there in the database

4> UserA deleted the node , saves and UserB trying to modify the same
NH Solution :Again state is not available can not use version

5> UserA Modified the node , saves and UserB tries to delete that
NH Solution: We can use the version here



Top
 Profile  
 
 Post subject:
PostPosted: Wed May 17, 2006 6:10 am 
Expert
Expert

Joined: Tue Aug 23, 2005 5:52 am
Posts: 335
Actually, I have had the same problem for situation 1 for some time and the only solution I've found is to use versioning along with read-committed transactions so that you can re-query your objects before allowing changes.

Normally when NH executes a query it flushes any changes to the state of any of the entities in the session to the DB so that they can be included in the query results (preventing stale data).

In your case you need to be able to query to make sure that no-one else has created an entity that is a duplicate of the one you want to insert but if you have added another duplicate yourself in the same session you can't query for it until it's flushed, so flushing must be allowed (it can be disabled on the session, but if you do you then queries will not include changes made to entities in your session, including, usuall, newly saved entities).

Since the query will flush the state of changes you've made in the session when you query you might have some data that gets flushed to the database before you really want it there (you may not want others to access the flushed data until you've finished making other changes, for example), so you should wrap the entire process in a transaction. Personally I use Read-Committed transactions to prevent other users accessing the data.

So to address your points specifically:

For 1 you need to query before saving the new node to the session. The session needs to flush any previous changes so that the query is accurate so you need a transaction in case you decide you don't want the changes that were fushed.

For 2 standard versioning covers this.

For 3 I think standard versioning covers this. I assume a SQL delete statement will only be executed if the item exists in the DB and is the same version or an exception will be thrown. Not sure about this though - anyone got any ideas?

For 4 if UserB is trying to update a node that has been deleted should be thrown since you can't update something that doesn't exist. If you use SaveOrUpdate then it'll re-create it if it's been deleted. Again, I'm not 100% sure about this.

For 5 standard versioning covers this. I think.

Lots of things I can't confirm here, but you could write some tests that have two sessions open to confirm these behaviors yourself if no one else can answer.

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 17, 2006 8:29 am 
Contributor
Contributor

Joined: Wed May 11, 2005 4:59 pm
Posts: 1766
Location: Prague, Czech Republic
If you don't want to use <version>, you can try using <class optimistic-lock="dirty"> or optimistic-lock="all". But having a version column is preferred.

Delete checks version in NHibernate (if there is a version property).

Most of the listed scenarios are actually addressed by the database itself. 1 is handled by the primary key constraint, 3 and 4 are handled by UPDATE/DELETE returning 0 affected rows which will cause an exception.


Top
 Profile  
 
 Post subject: about concurrency
PostPosted: Wed Jul 12, 2006 8:56 am 
Beginner
Beginner

Joined: Tue Feb 28, 2006 3:16 am
Posts: 28
Is anyone sure about the ways where i dont want to use versioning that is provided NH and still the concurrency is achivable.

I dont want to use versioning fearture of NH at all.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 13, 2006 4:38 am 
Beginner
Beginner

Joined: Tue Jan 17, 2006 12:55 pm
Posts: 49
Rather than get the tree from the database, I'd store it in an application cache and lock, change and unlock it each time there is to be a change.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.