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 <[EMAIL PROTECTED]> 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
>
--
-----------------------------------------< [EMAIL PROTECTED] >---
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 >---
