On 10/4/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
The issue of concurrent node modifications from different sessions not
being supported has (again) recently been raised. It seems like a
really useful feature that is only prevented by the limitations of the
current NodeState implementation. Are there other reasons why we
couldn't support such modifications?
the main problems are maintaining consistency of same-name sibling subscripts
and order of child nodes.
the spec clearly states that adding/removing child node entries causes a
modification of the parent node, i.e. adding a child node requires the parent
to be saved as well. the current behavior of jackrabbit is in accordance with
the spec. however, a more sophisticated approach to determine whether a
node is 'stale' would be to analyze the modifications rather than deciding
based on the 'modifiied' flag alone.
i created a jira issue that addresses the handling of trivial changes:
https://issues.apache.org/jira/browse/JCR-584
cheers
stefan
More fundamentally, I'd be interested in finding out ways to separate
the parent-child relationship handling from the parent NodeState. The
current design is the root cause for us not supporting content models
with unlimited children per node.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
