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 <[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
>
