jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Possible deadlock of jcr-server 1.2.1 (rmi)
Date Wed, 14 Mar 2007 11:22:11 GMT
> > imo, we can't fixed the transaction/concurrency issues that occur
> > together with versioning without a bigger redesign of some of the core
> > parts of jackrabbit.
>
> Do we have some directions that seem worth pursuing? Would rethinking
> the locking mechanisms be enough, or do we need to fundamentally
> modify the basic ItemStateManager and VersionManager designs?

well. one of the problems are the 'virtual item states'. in a first
place they were introduced in the believe that the version manager
could be replaced by another implementation that does not use the
repository itself for storing the versions. but now i think this will
never happen (and will not work anyway with the current architecture).
with a proper separation from the version (i.e. system) workspace from
the other workspaces and an overlay mechanism that perhaps takes place
on a higher layer (e.g. item manager) we could circumvent some of the
concurrency issues.
further inspection needs the transaction handling - this should
provide a more global transaction that could span updates on multiple
workspaces (and should allow including the persistence manager
backends as xa resource).

regards, toby
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message