On Thu, Feb 25, 2010 at 3:59 PM, Felix Meschberger <[email protected]> wrote: > 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 ....
why? (almost) every method would just need to synchronize on the session instance. cheers stefan > > 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 >> >
