Hi, On 25.02.2010 10:05, Jukka Zitting wrote: > 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.
So you also synchronize all Node/Item/Property methods and ensure that for a given Item x, the same Item instance is always returned from all getXXX methods .... The longer I think of it, the longer I am scared and the longer I am convinced, that this will be a situation, that has the potential of getting my veto.... Regards Felix > > 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 >
