Hi, On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg <[email protected]> wrote: > On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger <[email protected]> wrote: >> A big -1 (I already see the deadlocks in front of me) > > if there are deadlocks caused by such a change then the api's clearly being > misused (i.e. concurrent use of session instances) and there's a risk of data > corruption.
In fact, even concurrent use of sessions couldn't trigger deadlocks in this case, since for a deadlock you'd need something that already has locked a deeper repository resource to try locking the session. The only cases I can think of where such a reverse order of locking is possible are observation listeners and item state change notifications. It's feasible that we still have some lurking concurrency issues in those areas (there were a few that we already fixed, see JCR-2443 for an example), but I prefer deadlocks (that give you easily traceable thread dumps) to potential cases of corrupted internal state (that are notoriously difficult to troubleshoot). So yeah, +1 to Thomas' suggestion. We shouldn't be relying on client applications to maintain proper concurrency control. BR, Jukka Zitting
