You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Przemyslaw Pakulski <pp...@o2.pl> on 2006/03/10 16:04:22 UTC
Transaction isolation level support
Hi,
We are introducing transactions to our system, and run some concurrency
tests. We read in jsr170 spec that transactions should be completely
isolated from each other.
Considering following simple block of code :
> folder = getFolder(session);
> CrxUserTransaction ut = new CrxUserTransaction(session);
>
> 0 ut.begin();
> 1 folder.checkout();
> 2 Node child = folder.addNode("child");
> 3 child.addMixin("mix:versionable"); 4 child.setProperty("id", id);
> 5 child.setProperty("iteration", i);
> 6 folder.save();
> 7 child.checkin();
> 8 folder.checkin();
> 9 ut.commit();
We noticed different exceptions in different lines, executing this block
concurrently :
- line 1 - InvalidItemStateException : the item does not exist anymore,
- line 6 - InvalidItemStateException : item cannot be saved because it
has been modified externally,
- line 9 - XAException caused by StaleItemStateExcpetion :
{http://www.jcp.org/jcr/1.0}isCheckedOut has been modified externally
Certainly we don't share session between threads, we use dedicated
session for each thread.
So, it looks like transactions can see changes made by other
transactions, what means jackrabbit doesn't support SERIALIZABLE and
even REPETABLE_READ isolation level, but only READ_COMMITTED level.
Can anybody explain what really isolation level is supported by
jackrabbit implementation currently ?
Regards
Przemo Pakulski
www.cognifide.com
Re: Transaction isolation level support
Posted by Dominique Pfister <do...@day.com>.
Hi Przemo,
transaction isolation level currently supported by jackrabbit is in
fact READ-COMMITTED, i.e. a transaction can only see modifications
committed by other transactions, but such a committed modification may
affect reads of this transaction.
Regards
Dominique
On 3/10/06, Przemyslaw Pakulski <pp...@o2.pl> wrote:
> Hi,
>
> We are introducing transactions to our system, and run some concurrency
> tests. We read in jsr170 spec that transactions should be completely
> isolated from each other.
>
> Considering following simple block of code :
>
> > folder = getFolder(session);
> > CrxUserTransaction ut = new CrxUserTransaction(session);
> >
> > 0 ut.begin();
> > 1 folder.checkout();
> > 2 Node child = folder.addNode("child");
> > 3 child.addMixin("mix:versionable"); 4 child.setProperty("id", id);
> > 5 child.setProperty("iteration", i);
> > 6 folder.save();
> > 7 child.checkin();
> > 8 folder.checkin();
> > 9 ut.commit();
>
> We noticed different exceptions in different lines, executing this block
> concurrently :
> - line 1 - InvalidItemStateException : the item does not exist anymore,
> - line 6 - InvalidItemStateException : item cannot be saved because it
> has been modified externally,
> - line 9 - XAException caused by StaleItemStateExcpetion :
> {http://www.jcp.org/jcr/1.0}isCheckedOut has been modified externally
>
> Certainly we don't share session between threads, we use dedicated
> session for each thread.
>
> So, it looks like transactions can see changes made by other
> transactions, what means jackrabbit doesn't support SERIALIZABLE and
> even REPETABLE_READ isolation level, but only READ_COMMITTED level.
>
> Can anybody explain what really isolation level is supported by
> jackrabbit implementation currently ?
>
> Regards
> Przemo Pakulski
> www.cognifide.com
>
Re: Transaction isolation level support
Posted by Tobias Bocanegra <to...@day.com>.
hi przemo,
transactions should be read-repeatable. error on line 9 is ok, if the
same node was modified by another transaction before. can you please
file a jira issue? thanks.
regards, toby
On 3/10/06, Przemyslaw Pakulski <pp...@o2.pl> wrote:
> Hi,
>
> We are introducing transactions to our system, and run some concurrency
> tests. We read in jsr170 spec that transactions should be completely
> isolated from each other.
>
> Considering following simple block of code :
>
> > folder = getFolder(session);
> > CrxUserTransaction ut = new CrxUserTransaction(session);
> >
> > 0 ut.begin();
> > 1 folder.checkout();
> > 2 Node child = folder.addNode("child");
> > 3 child.addMixin("mix:versionable"); 4 child.setProperty("id", id);
> > 5 child.setProperty("iteration", i);
> > 6 folder.save();
> > 7 child.checkin();
> > 8 folder.checkin();
> > 9 ut.commit();
>
> We noticed different exceptions in different lines, executing this block
> concurrently :
> - line 1 - InvalidItemStateException : the item does not exist anymore,
> - line 6 - InvalidItemStateException : item cannot be saved because it
> has been modified externally,
> - line 9 - XAException caused by StaleItemStateExcpetion :
> {http://www.jcp.org/jcr/1.0}isCheckedOut has been modified externally
>
> Certainly we don't share session between threads, we use dedicated
> session for each thread.
>
> So, it looks like transactions can see changes made by other
> transactions, what means jackrabbit doesn't support SERIALIZABLE and
> even REPETABLE_READ isolation level, but only READ_COMMITTED level.
>
> Can anybody explain what really isolation level is supported by
> jackrabbit implementation currently ?
>
> Regards
> Przemo Pakulski
> www.cognifide.com
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---