On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger <fmesc...@gmail.com> 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. it's IMO better to detect and fix such improper api usage. cheers stefan > > If we want to make sessions thread-safe, we should use proper > implementations. On the other hand, it is probably really better to > stick with the current setup of "a session is not thread-safe" and any > concurrent use of the same session is unsupported. > > Regards > Felix > > On 24.02.2010 18:34, Thomas Müller wrote: >> Currently, Jackrabbit sessions are somewhat synchronized, but not >> completely (for example it's still possible to concurrently read and >> update data). There were some problems because of that, and probably >> there still are. >> >> I believe it's better to synchronize all methods in the session (on >> the session object). This includes methods on nodes and properties and >> so on. If this does turn out to be a performance problem, we can >> remove synchronization where required (and where it can safely be >> removed) or change the implementation (use immutable objects or safe >> data structures). >> >> This is more conservative, but I think the impact on performance will >> be minimal. Of course performance is important, however I think data >> consistency is more important than the possible gain of a few percents >> of (read-) performance. >> >> Regards, >> Thomas >> > >
