jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: enter() method for JCR implementation classes
Date Wed, 20 Feb 2013 21:36:04 GMT

On Tue, Feb 19, 2013 at 10:47 PM, Michael Dürig <mduerig@apache.org> wrote:
> The problem is that SessionDelegate.needsRefresh() requires clean up after
> the "real" method returns.

We could refactor the code so that such clean up is not needed.

AFAICT the mechanism is currently used to avoid repeated refreshing of
the session from nested operations. An alternative design would be to
turn needsRefresh to a flag in SessionDelegate that could be raised by
observation and other things like that. The enter() method would then
trigger a refresh and clear the flag, which would prevent further
nested operations from repeatedly refreshing until the flag gets
raised again.

> [...] 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.

The delegate pattern should allow us to avoid these cases. Instead of
JCR methods calling each other, they could be calling the relevant
delegate methods directly.

> 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.

Agreed, the performance concern is probably a non-issue.

Another worry is that the pattern makes tracking control flow rather
complicated for example when trying to step through the code in a
debugger. In practice I end up setting extra breakpoints inside the
anonymous SessionOperation classes to be able to step to inside them.


Jukka Zitting

View raw message