jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume ...@nuxeo.com>
Subject Re: Isolation level inconsistency.
Date Thu, 16 Aug 2007 16:54:59 GMT
Peeter Piegaze wrote:
> On 8/14/07, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
>> Florent Guillaume wrote:
>>> In JCR, there are *three* stages, the first stage being the transient
>>> space.
>>>
>>> 1. The data you write is transient.
>>> 2. You save() the transient space and it becomes the equivalent
>>>    of "uncommitted" in a RDB, and is taken into account in
>>>    searches.
>>>    Or you can refresh() and all *or part of* your transient changes
>>>    are lost (you have granularity here).
>> jackrabbit does not take into account saved changes that are not yet committed.
>> after looking up the relevant spec section again, it seems to me that the spec
>> is not clear about this:
>>
>> 6.6.7 Search Scope
>> "A query searches the persistent workspace associated with the current session.
>> It does not search any pending changes that may be recorded on the session but
>> not yet saved."
>>
>> The first sentence implies that you have to commit before you can search your
>> changes. the second sentence says that you cannot search transient changes. it
>> doesn't really say what happens with saved, yet uncommitted changes.
> 
> The spec is written throughout as if transactions are not present.
> Section 8.1.3 Save vs.Commit says:
> 
> "Throughout this specification we often mention the distinction
> between transient and persistent levels. The persistent level refers
> to the (one or more) workspaces that make up the actual content
> storage of the repository. The transient level refers to in-memory
> storage associated with a particular Session object.
> 
> In these discussions we usually assume that operations occur
> outside the context of transactions; it is assumed that
> save and other workspace-altering methods immediately effect changes to
> the persistent layer, causing those changes to be made visible to
> other sessions.
> 
> This is not the case, however, once transactions are introduced.
> Within a transaction, changes made by save (or other, workspace-
> direct, methods) are transactionalized and are only persisted and
> published (made visible to other sessions), upon commit of the
> transaction. A rollback will, conversely, revert the effects of any
> saves or workspace-direct methods called within the transaction. "
> 
> Basically it means that in the context of transactions any mention of
> "save" in the spec must be read as "save + commit"

I don't agree. I read it as "in the context of a transaction, things 
behave in exactly the same way from the point of view of the session 
that opened the transaction, but others session will see only committed 
changes."

That's the point of the transaction. Otherwise if would mean that you'd 
have different semantics when you switch from one session that works 
alone without transactions, to a session that is in a transaction 
because there may be other concurrent ones.

> So, taking that section along with the 6.6.7 Search Scope its clear
> that jackrabbit does implement according to spec. Whether this is the
> best behavior is another question.

It's not clear for me that this is what has to be read in the spec.

Florent


-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Mime
View raw message