jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iapilgrim <iapilg...@gmail.com>
Subject Re: Clarification on Node refresh
Date Wed, 22 Oct 2008 07:56:50 GMT

Now, I understand.
With copy-on-write strategy, in one session, if an item has not been
modified yet then getNode (or query...) will reflect the changes made by
other session.
But when that item is modified, it will be copied to transient storage, and
when we getNode subsequently, the returned node will be the same as the node
in the transient storage ( we are mentioning to one session).
Is that right?

Alexander Klimetschek wrote:
> 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
> value.
> 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.
> Regards,
> Alex
> 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
> alexander.klimetschek@day.com

View this message in context: http://www.nabble.com/Clarification-on-Node-refresh-tp20019799p20105769.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message