Hi, On Tue, Feb 19, 2013 at 10:47 PM, Michael Dürig <mdue...@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. BR, Jukka Zitting
