jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: Clarification on Node refresh
Date Wed, 22 Oct 2008 07:27:29 GMT
Following to (or "Re-using item objects", it makes
things a bit more clear:

Whether the second Item  object is the same actual Java object
instance as the first is an implementation issue. However, the state
reflected by the object must at all times be consistent with any other
Item object (associated with the same Session) representing the same
actual item entity. Note that the criteria of item identity in this
context are those described above in 7.1.2 Saving by UUID and Path.

Since the actual data you read in the end are property values, ie.
strings, longs, binaries etc., where the JCR implementation no longer
has control over if you read it, this description only talks about
node and property objects. Which means (and I think that is how it
works in Jackrabbit) that if you do

Property prop = session.getItem("/some/path/foo");

and subsequently do a prop.getString(), you might get different
results if someone modified the value on the repository. Same for
node.getNode() and node.getProperty() in the first step. The item
objects always point to the most recent value if you ask them for a

Typical JCR program style (for reading) is to get a node, read its
properties values and then immediately discard the node and property
objects anyway.


On Wed, Oct 22, 2008 at 5:32 AM, iapilgrim <iapilgrim@gmail.com> wrote:
> Hi Alex,
> With copy-on-write strategy, two subsequents read can give different
> results. But when I read in JCR spec (6.2.3 Node Read Methods).
> getNode(String relPath):  Returns the node at relPath  relative to this
> node.
>  Within the scope of a single Session  object, if a node has been acquired
> with getNode , any subsequent call of getNode  reacquiring the same node
> must return a Node  object reflecting the same state as the earlier Node
> object.
> Whether this object is actually the same Node  instance, or simply one
> wrapping the same state, is up to the implementation. See Re-using
> Item Objects .
> --> Does it mean we always get the same state of a Node ( in a Session) no
> matter what which strategy is ( copy-on-write or copy-on-read).
> I'm really confused. Could you explain it to me?
> Van
> Alexander Klimetschek wrote:
>> (2) copy-on-write (Jackrabbit), where a node is copied into the
>> transient space only when you modify it. This means all reads to
>> non-modified nodes will always give the most up-to-date veersion of
>> that node. That also implies two subsequents read can give different
>> results (which would not be the case for the copy-on-read variant). In
>> this case refresh() has no effect on non-modifed nodes. Jackrabbit
>> uses this variant since it is much more useful for most applications
>> (ie. you would permanently re-login to get a new session or call
>> refresh for all read operations).
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
> --
> View this message in context: http://www.nabble.com/Clarification-on-Node-refresh-tp20019799p20103437.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Alexander Klimetschek

View raw message