Re: enter() method for JCR implementation classes

2013-04-25 Thread Jukka Zitting
Hi, On Tue, Mar 5, 2013 at 11:56 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: - dlg.perform(dlg.getSomeOperation(oakName, ...)) Thinking further about this, it seems like it would make sense to push the perform() mechanism entirely to the delegate level, simplifying the above call to just

Re: enter() method for JCR implementation classes

2013-03-08 Thread Jukka Zitting
Hi, On Fri, Mar 8, 2013 at 3:32 PM, Michael Dürig mdue...@apache.org wrote: 2) Synchronize SessionDelegete.perform(), which effectively serializes *all* JCR calls on a single session. As mentioned earlier, this is what I'd do. A client for which this is a problem can always open new sessions

Re: enter() method for JCR implementation classes

2013-03-08 Thread Michael Dürig
On 8.3.13 13:41, Jukka Zitting wrote: Hi, On Fri, Mar 8, 2013 at 3:32 PM, Michael Dürig mdue...@apache.org wrote: 2) Synchronize SessionDelegete.perform(), which effectively serializes *all* JCR calls on a single session. As mentioned earlier, this is what I'd do. A client for which this

Re: enter() method for JCR implementation classes

2013-03-05 Thread Michael Dürig
On 5.3.13 9:56, Jukka Zitting wrote: 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

Re: enter() method for JCR implementation classes

2013-02-27 Thread Jukka Zitting
Hi, On Wed, Feb 27, 2013 at 11:51 AM, Michael Dürig mdue...@apache.org wrote: The problem is actually more subtle than that. The mechanism avoids refresh being called from reentrant calls to any session scoped operation (that's the reason for using a counter in perform). Otherwise we risk that

Re: enter() method for JCR implementation classes

2013-02-27 Thread Michael Dürig
On 27.2.13 12:50, Jukka Zitting wrote: Hi, On Wed, Feb 27, 2013 at 11:51 AM, Michael Dürig mdue...@apache.org wrote: The problem is actually more subtle than that. The mechanism avoids refresh being called from reentrant calls to any session scoped operation (that's the reason for using a

Re: enter() method for JCR implementation classes

2013-02-27 Thread Jukka Zitting
Hi, On Wed, Feb 27, 2013 at 3:00 PM, Michael Dürig mdue...@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

Re: enter() method for JCR implementation classes

2013-02-20 Thread Jukka Zitting
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

enter() method for JCR implementation classes

2013-02-19 Thread Jukka Zitting
Hi, The current boilerplate for most of the methods in our JCR implementation classes looks something like this: public Something getSomething() { checkStatus(); return sessionDelegate.perform( new SessionOperationPropertyImpl() { @Override