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" 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
