Peeter Piegaze wrote:
On 8/14/07, Marcel Reutegger <[EMAIL PROTECTED]> 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
