jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Belisle <Nicolas.Beli...@bibl.ulaval.ca>
Subject Re: Problems with concurrent sessions
Date Fri, 08 Jul 2005 15:51:25 GMT
Hi,

Many thanks for your response.

 > no, but you may use locks to further control isolation level.

There seems to be at least two problems with that approach :

- You will get a (unpleasant) javax.jcr.lock.LockException if another 
transaction tries to lock the node (or a child).
- It is not enforced even though it should be used everywhere, even for 
only a read.

 > I cannot quite follow you here. thread B seems to save a session without 
having
 > made  changes to it? that means 'B : save session' is basically no op. 
But I guess
 > that's not  what you want to know...

Sorry there was an error in my example. I should make more sense this way :

Example v.2 :
A : open session
A : read nodes "test" & "test2"
B : open session
B : delete nodes "test" & "test2"
B : save session //WHAT SHOULD HAPPEN ??
B : logout
A : read nodes "test" & "test2" //WHAT SHOULD HAPPEN ??
A : logout

It would be useful if the isolation level could configured at the 
repository level. So if your application needs better isolation or 
performance you would only need to change the configuration and not your code.
An implementation could (hypothetically) use locks in SessionImpl and use 
events (when a session saves/logout) to prevent throwing exceptions. A 
queue would hold pending operations. However, we would have to be careful 
about long lived sessions...

What do you think ?

Regards,

Nicolas


Le 04:06 2005-07-08, vous avez écrit:
>Hi Nicolas,
>
>Nicolas Belisle wrote:
>>What is the session isolation level [ref. 
>>http://www.unix.org.ua/orelly/java-ent/ebeans/ch08_03.htm] by default ?
>
>the default is read commited.
>
>>Is it configurable ?
>
>no, but you may use locks to further control isolation level.
>
>a session in jackrabbit will see changes as soon as they are committed. 
>you may however use locks to achieve a higher isolation level. 
>successfully setting a lock on a node will give you repeatable read for 
>that subtree. if you do that on the root node you get serializable 
>isolation level.
>
>>At least, Jackrabbit seems to prevent dirty reads (determined from 
>>tests). Is there any documentation regarding isolation level ? I think it 
>>is a very important topic...
>
>Unfortunately there is currently no documentation on isolation levels, but 
>this thread may be a good starting point to collect all relevant 
>information and then put it into a nice xdoc or wiki page.
>
>>Example :
>>A : open session
>>A : read nodes "test" & "test2"
>>B : open session
>>A : delete nodes "test" & "test2"
>>B : save session //WHAT SHOULD HAPPEN ??
>>B : logout
>>A : read nodes "test" & "test2" //WHAT SHOULD HAPPEN ??
>>A : logout
>
>I cannot quite follow you here. thread B seems to save a session without 
>having made changes to it? that means 'B : save session' is basically no 
>op. But I guess that's not what you want to know...
>
>regards
>  marcel


Mime
View raw message