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 Mon, 13 Aug 2007 15:47:36 GMT
IvanLatysh wrote:
> Jukka Zitting wrote:
>> Hi,
>>
>> On 7/20/07, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
>>> AFAIK databases simply don't support the concept of transient changes.
>>> please note that the JCR save() is not the equivalent of a db commit().
>>
>> Well said! A better analogue, as already mentoned, is 
>> Statement.execute().
> 
> Also we can state that DB results are immutable, but it does not change 
> the subject.
> 
> Let's put is this way.
>  * RDBMS provide a way to query not-commited changes
>  * I expect JCR to provide a way to query not-persisted changes


You and other people are being confused by the fact that JCR is more
powerful than the standard uncommitted/committed model.


In a classic RDB there are two stages:

1. The data you write is uncommitted. You can search it.
2. You commit() the transaction and other sessions can see the changes.
    Or you can rollback() and all your changes are lost.


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).
3. You commit() the transaction and the changes become visible
    to other sessions.
    Or you can rollback() and all your changes are lost.


Anyone who doesn't see and understand this model is missing the point.

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