jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: Isolation level inconsistency.
Date Thu, 19 Jul 2007 22:10:06 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message