Hi, > jdbc connection is not thread safe. jcr session works similar way and I > prefer follow the same pattern.
Me too. But there is a difference between "thread safety" and "consistency". I don't know of a relational database that allows you to violate referential integrity, unique key constraints, or check constraints - simply by using the same connection in multiple threads. See also http://en.wikipedia.org/wiki/ACID Jackrabbit did and does have such problems (nodes that point to non-existing parent nodes; nodes that point to non-existing child nodes). *Those* are the problems I want to solve. Jackrabbit shouldn't try to protect an application from storing the "wrong" data. It can't. Application developers are responsible for ensuring application level consistency (this sentence stolen from Wikipedia). > To what avail? It should never be necessary to run a "consistency check" or "consistency fix". It should never be necessary to delete nodes because they are "corrupt". Nodes should never get corrupt. > programmers ... If they do not, it is their fault and they have to live with > the consequences of their doing the wrong thing. Unfortunately, it's not that simple to find out whose program caused the problem. Usually other people have to fix the problem than those who caused them. > But not with synchronizing all methods. As I already wrote, if this does turn out to be a performance problem, we can remove synchronization where required. Regards, Thomas
