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 Tue, 19 Feb 2013 20:47:41 GMT


On 19.2.13 15:51, Jukka Zitting wrote:
> So, to simplify things I propose that we refactor the above code to
> something like this:
>
>      public Something getSomething() {
>          enter("doSomething");
>          return ...;
>      }

The problem is that SessionDelegate.needsRefresh() requires clean up 
after the "real" method returns. Using a closure like approach frees the 
caller from this responsibility. In your approach you would probably end 
up forcing each client method having to call a leave() method after the 
"real" work is done. Forgetting to do so would break the refresh 
invariants.

I agree that there is to much boilerplate though. Some of it stems from 
the Java encoding of closures and some of it stems from the various 
precondition checks. The former is pretty well hidden by modern IDEs and 
will go away soon anyway (when Java 42 is out ;-) ). The latter is IMO 
better tackled by enriching 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.

Regarding the cost of the extra object allocation, I think the JVM is 
pretty efficient with handling these and we shouldn't jump to conclusion 
until we have figures on the performance drain caused by this. If this 
turns out to be a problem we still can get rid of the per call 
allocations by using pre allocated instances and by passing in a more or 
less generic environment.

Michael




Mime
View raw message