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 Mon, 23 Jul 2007 16:07:09 GMT

I understand that you have efficiency related concerns. Fair enough.
However, this is a discussion of the semantics of the spec, not
implementation discussion. As well, this is the user list, I would assume
that implementation discussions would belong in the dev mailing list...

Secondly, I know the original poster suggested only one way (update query
results with transient state) but I've stated twice before that either that
approach or just showing the persistent state (without ANY transient
information) would be acceptable to me:
"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
  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!"

Please note the *or* in the proposal that I gave, and read my full post for
all the details.



so far I haven't seen a proposal how the desired semantics (query
> operating on the transient state) can be implemented efficiently at all,
> without closely coupling the transient space implementation to the
> storage. And, as a matter of fact, the contrary (de-coupling them) is
> what's currently being done in the Jackrabbit SPI work.
So, I'm not opposed to discuss this, but right now I just don't see how
> to implement that.
> For the record, I'm fine with *allowing* repositories to implement that
> (but not making it required).
> Best regards, Julian


Mark Waschkowski

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message