jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: enter() method for JCR implementation classes
Date Thu, 28 Feb 2013 11:13:12 GMT

On 27.2.13 13:14, Jukka Zitting wrote:
> Hi,
> On Wed, Feb 27, 2013 at 3:00 PM, Michael Dürig <mduerig@apache.org> wrote:
>> I am though. Such in flight refreshes render internal invariants to break.
> Fair enough.
> The other alternative, as discussed, would be to utilize better
> control over the Impl/Delegate barrier. You're right in that this
> would be troublesome to enforce manually given the size of the JCR
> API. Perhaps we could use static analysis for that.

Just some anecdotal evidence: a single call to Node.addNode() results in 
a call to Node.getPrimaryNodeType() which in turn ends up calling 
Property.getValue() and which eventually results in a call to 
Property.isMultiple(). So there will be quite a bit of stuff to 
untangle. Not sure how to go about this in order to catch them all.

OTOH as your main concern initially was to reduce boilerplate, we could 
also try the other approach I proposed earlier: enrich SessionOperation 
with preconditions to be checked before the core of the call is actually 
executed. This will at the same time address the issue I brought up at 
our last meeting that implementing JCR method in terms of each others 
will result in the preconditions being checked multiple times instead of 
just once. Furthermore such an approach would also close the race we 
currently have between the calls to the check methods and the actually 
operation being performed. Currently there is still the chance, that the 
conditions become invalid right after the check methods returned but 
before the operation is actually performed.


> BR,
> Jukka Zitting

View raw message