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:56:55 GMT
Marcel Reutegger 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.

"persistent workspace", in the absence of transactions, is whatever has 
been saved. As transactions are not supposed to change the semantics, 
but just provide a level of isolation/rollback with the rest of the 
world, to me it still means "whatever has been saved" when transactions 
are enabled.

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