jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hendrik Beck \(camunda\)" <hendrik.b...@camunda.com>
Subject RE: Isolation level inconsistency.
Date Thu, 19 Jul 2007 23:20:35 GMT
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?


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