Hi, On 25.02.2010 16:33, Thomas Müller wrote: > Hi, > >> this creates a big potential for deadlocks > > Could you provide an example on how such a deadlock could look like?
I don't have an example off hand, and as Jukka said, it might well be, that there might be none. Still the potential exists, especially if the session is not fully synchronized... > >> just synchronizing all methods >> So you also synchronize all Node/Item/Property methods > > Some methods don't need to be synchronized, for example some getter > methods such as Session.getRepository(), RangeIterator.getPosition() > and getSize(). I'm not sure if Node.getProperty needs to be > synchronized. The Value class is (almost) immutable so synchronization > is not required here. But very likely Session.getNode(..) and > Node.getNode() need to be synchronized because those potentially > modify the cache. > >> ensure that for a given Item x, the same Item instance is always returned >> from all getXXX methods .... > > I'm not sure what you are referring to. Jackrabbit already does ensure > the same node object is returned as far as I know, but for other > reasons than synchronization. > >> if people do the wrong things, well, fine, let them do ... > > It's usually not those people that have to fix broken repositories. > >> my veto > > Let's see. ;-) Regards Felix > >> Most jcr apps I've seen often use a single session from several threads to >> read from this session. (I think I also read it somewhere that this is safe >> with jackrabbit, but I might be mistaken). > > I'm not sure if this is really safe. Maybe it is problematic if one > thread uses the same session for updates. > >> Simply syncing everything on the session would decrease performance in these >> cases dramatically. > > Actually, I don't think that's the case. > > Regards, > Thomas >
