jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Doubleday <daniel.double...@gmx.net>
Subject Re: Best practice for working with multiple sessions needed
Date Sun, 24 Sep 2006 14:08:47 GMT

Thanks for the fast reply,

I think that I posted the wrong question and my real question is silly. 

My application includes many use cases where it has to be able to add many
'n' in an 1-n relationship concurrently. Think of a blog where the the 1 is
the blog entry folder and the n's are the entries. Many users will be adding
entries at the same time. In an RDBM System that's no bi deal since the blog
entry folder never has to be updated when a new entry is added.

With JCR the child node references are stored in the parent node. Thus the
locking problem. I think that's simply the price of JCR and my app is not
suitable.

Thanks anyway,
Daniel


Alexandru Popescu-3 wrote:
> 
> On 9/24/06, Daniel Doubleday <daniel.doubleday@gmx.net> wrote:
>>
>> Hi all,
>>
>> The problem scenario is concurrent application (web)
>>
>> The following pseudo code tries to explain the general problem:
>>
>> // thread a
>> Node userANode = userASession.getRootNode().getNode("somenode");
>>
>> // thread b
>> Node userBNode = userBSession.getRootNode().getNode("somenode");
>>
>> // thread a
>> userANode.addNode("foo");
>>
>> // thread b
>> userBNode.addNode("bar");
>>
>> // thread a
>> userANode.save();
>>
>> //thread b
>> userBNode.save();
>> // crash
>>
>> Since the node "somenode" was modified in two sessions the thread that
>> tries
>> to do the second save will fail because of the "external" modification.
>>
>> 1. my main problem is that I don't see an easy way of how to recover from
>> such a crash. I don't even see a way to check first because ItemState is
>> jackrabbit internal
>> 2. I believe that in almost every webapp adding a node to some special
>> entry
>> node (such as a folder for messages) is very common.
>> 3. using a shared session does not seem to be an option (synch issue)
>>
>> Is there some sort of best practice working with multiple sessions? Does
>> this mean that one has to implement an application specific locking
>> mechanism?
>>
>> Cheers, Daniel
>>
> 
> I think for concurrent write access you should start looking into the
> locking API offered by JCR. This will probably require some small code
> changes (if you already have the code) or shifting a bit the way you
> plan to implement it (find the parent node, lock it for write, write,
> unlock).
> 
> HTH,
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Best-practice-for-working-with-multiple-sessions-needed-tf2326328.html#a6471987
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Best-practice-for-working-with-multiple-sessions-needed-tf2326328.html#a6472477
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message