jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Isolation level inconsistency.
Date Fri, 20 Jul 2007 07:46:35 GMT
On 7/20/07, Hendrik Beck (camunda) <hendrik.beck@camunda.com> wrote:
> Aren't you missing an important point in this discussion? Maybe someone who
> is deeper into the spec and the Jackrabbit architecture can correct me if I
> am wrong but I understand it like that:
>
> 1) Accessing nodes always takes the transient state of my own session into
> account. That means, if I make changes, don't save them yet and then access
> my own nodes again, I will see my own changes. But I never see any transient
> changes of another session. That's clear, I think.
>
> 2) Searching always accesses the persistent state only. That means, I can't
> search for any transient changes, whether they were made by my session or by
> another session. But, and that's the important point (I guess), if I get my
> search results and then try to ACCESS one of these nodes from my search
> results, then I will (according to point 1) see the transient state of these
> nodes. But again, only MY transient changes, not the transient changes of
> someone else. This is the case where search result and accessed nodes can be
> different. For example:
>
> 1) The persistent state of a contact node has the name "Joe"
> 2) I change the name to "John" but don't save it (it's still transient for
> me or my session respectively)
> 3) If I access that node, I will see the (transient) name "John"
> 4) When I search for "Joe", I will still find that node, because searching
> only takes the persistent state into account
> 5) But when I now access this node (that I just found under the name "Joe"),
> then I will see the name "John"
>
>
> Of course, there might be discrepancies in such a case, but 1) it seems to
> be pretty clear to me how it works and 2) the spec says the following about
> that to avoid it if necessary:
>
> "Applications can clear the Session (either through save or refresh(false))
> before running a query in order to avoid such discrepancies."
>
>
> Does that make sense for you?

perfectly, that's an excellent and concise explanation.

cheers
stefan

>
>
> Especially I think that this has nothing to do with accessing transient
> changes from other sessions. It's always about the transient changes of my
> own session.
>
>
> > -----Original Message-----
> > From: Mark Waschkowski [mailto:mwaschkowski@gmail.com]
> > Sent: Friday, July 20, 2007 5:10 AM
> > To: users@jackrabbit.apache.org
> > Subject: Re: Isolation level inconsistency.
> >
> > Actually, the more I think about it the worse it gets. I would like to
> > know
> > to whom the following makes sense:
> >
> > 1) Get session and load a contact with name 'Joe'
> > 2) Update the name property from 'Joe' to 'John'
> > 3) Now, query the repo for the contact using the name 'Joe'
> > 4) The node that you get back from the query will have the name property
> > as
> > 'John' even though the persisted state is 'Joe' and the query was based on
> > the name 'Joe'!
> >
> > Or, worse yet:
> > 1) Get session and load a contact with name 'Joe'
> > 2) Update the name property from 'Joe' to 'John'
> > 3) Add a new contact
> > 4) Query to get all the contacts and iterate through them
> > 5) See nodes that have an updated state, but don't see any of the newly
> > added nodes! Now you have a strange mix all the previously persisted
> > nodes,
> > nodes that have been updated in the session, but without any of the newly
> > added nodes!
> >
> > Maybe I'm totally missing the point, but I can't fathom *why* the spec
> > would
> > be written this way and really think it should just be one way or the
> > other.
> >
> >   ie. Either (ideally) respect the current session state and include ALL
> > session changes in the query results, or, if that is somehow
> > unacceptable/complicated/expensive operation etc., show me the persistent
> > state - just not some funky combination!
> >
> > "again you're proposing a major change to JCR. If a query would need to
> > take
> > transient changes into account, it needs
> > to operate both on the persisted state, and on the local transient space.
> > "
> > Some part of the local transient space is *already* being taken into
> > account
> > (ie. updates of nodes) so maybe handling additions/deletions would be a
> > major change or maybe not. Regardless, IMHO, I think the spec will make
> > more
> > sense if one way or the other (see above) is decided on, and now, during
> > the
> > public review phase would seem to me like the best time to take these
> > inconsistencies.
> >
> > Best,
> >
> > Mark
> >
> >
> > On 7/19/07, Mark Waschkowski <mwaschkowski@gmail.com > wrote:
> > >
> > > Hi Julian,
> > >
> > > I've actually brought this issue up with the version 1.0 of the spec and
> > > found it confusing. Using
> > >
> > >   session.getRootNode().getNode(path)
> > >
> > > 'sees' any transient changes already, so there is already support for
> > the
> > > transient changes within JCR and the session, albeit not using queries.
> > > Furthermore, SQL databases all see transient changes within the same
> > > transaction, so there is certainly precedent (and examples) for this
> > type of
> > > behavior...
> > >
> > > Best,
> > >
> > > Mark
> > >
> > > On 7/19/07, Julian Reschke < julian.reschke@gmx.de> wrote:
> > > >
> > > > IvanLatysh wrote:
> > > > > Julian Reschke wrote:
> > > > >
> > > > >> again you're proposing a major change to JCR.
> > > > > Sorry for my ignorance, but it is funny, you just dropped XPath and
> > > > you
> > > > > saying that fixing of an obvious mistake is a major change ?
> > > >
> > > > (1) I didn't drop, the EG basically proposes to drop it. It's under
> > > > public review, right? That being said, I'm in favor of keeping XPath
> > as
> > > > mandatory.
> > > >
> > > > (2) I strongly disagree that the current property data model is a
> > > > mistake; actually, I think it's the right design.
> > > >
> > > > >> If a query would need to take transient changes into account,
it
> > > > needs
> > > > >> to operate both on the persisted state, and on the local transient
> > > > >> space. Note that these may be on different machines. Maybe it's
> > just
> > > > >> me, but I have no idea how that could be implemented efficiently,
> > *in
> > > > >> particular* if you don't have the luxury to develop that
> > > > functionality
> > > > >> from scratch.
> > > > > I am sorry, but an implementation of that is a trivial task,
> > everybody
> > > > > does it.
> > > > > Have a look at any persistence engines.
> > > >
> > > > Well, you seem to be very sure, so I guess I won't argue with you and
> > go
> > > >
> > > > back to my JCR 1.0 L2 implementation, which does not and will not work
> > > > that way.
> > > >
> > > > Best regards, Julian
> > > >
> > >
> > >
> > >
> > > --
> > > Best,
> > >
> > > Mark Waschkowski
>
>

Mime
View raw message