On 27.2.13 13:14, Jukka Zitting wrote:
Hi,
On Wed, Feb 27, 2013 at 3:00 PM, Michael Dürig <[email protected]> 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.
Michael
BR,
Jukka Zitting
