Hi, > this creates a big potential for deadlocks
Could you provide an example on how such a deadlock could look like? > 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. > 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
