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:30:56 GMT
One more thing I want to say:

"again you're proposing a major change to JCR."

"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."


1) In my eyes the public review is there to give any feedback, to discuss
everything and to make proposals, whether they are major changes or just
little remarks.

2) I wouldn't agree that discussions about implementation details should be
part of a public review of a specification. Sure we should keep an eye on
the implementation, it has to be done at some point. But, we talk about JCR,
not Jackrabbit. The JCR specification shouldn't take care about
implementation details of one product (Jackrabbit), but it should find the
best way to make the specification according to people's needs and
requirements.


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