jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger" <marcel.reuteg...@gmx.net>
Subject Re: Isolation level inconsistency.
Date Wed, 25 Jul 2007 08:18:12 GMT
> > If query return persistent state only you will see a bit different 
> > behavior.
> >   1) query repo for node with property P=steve
> >   2) got node A with property P=steve
> >   3) set node A property P=john (making it transient, resulting in node
> A')
> >   4) query repository for node with property P=john
> >   5) got nothing
> >   6) query repo for node with property P=steve
> >   7) got node A (the original from the store because A' is still
> transient)
> > with property P=steve
> > 
> > And what Marcel was trying to say was:
> > 
> >   8) set node A property Q=test (making it transient, resulting in node
> A''
> > because it's not the same as the one in the store and also different
> from
> > A'? Or does something else happen?)
> >   9) What happens when we call save() or refresh() on A' or A''?
> > 
> refresh will do it's job per spec, no difference here.

but the spec doesn't cover the case when you have three instances of the same node: A, A'
and A''.

> Save will throw an exception when transient state has such conflict.

how do you resolve such a situation? let's say theoretically you can refresh A' in order to
save A'', how do you get to that node using a path or the UUID? e.g. if the node is referenceable
and I call Session.getNodeByUUID() will the method return A' or A''?

Returning transient nodes for QueryResult.getNodes() is the only reasonable option!

However I agree with you that a JCR implementation should be allow to also consider transient
changes when executing a query.

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

View raw message