jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peeter Piegaze" <peeter.pieg...@day.com>
Subject Re: Isolation level inconsistency.
Date Tue, 14 Aug 2007 16:22:09 GMT
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"

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.

Cheers,
Peeter

>
> regards
>   marcel
>
> > 3. You commit() the transaction and the changes become visible
> >    to other sessions.
> >    Or you can rollback() and all your changes are lost.
>
>


-- 
Peeter Piegaze

Day Software
Suite 331
67 Mowat Avenue
Toronto Ontario M6K 3E3
Canada

office +1 416 987 5720
mobile +1 647 205 2403
fax +1 866 719 3988

Mime
View raw message