Hi Shaun, moving to dev list ... In my case the problem was that the applicationserver (websphere) has changed the thread between acquiring writelock and the downgrade to a readlock so we are running into deadlock.
Have you tested the patched DefaultISMLocking Class ? >Hi Claus, >Thanks for the quick response. > >We're not intentionally using an XA transaction. We're using Spring + >Transaction Manager + Hibernate elsewhere to satisfy the request. > >....so a few quick questions: > >* Is there a way to force JackRabbit not to use XA? What are the alternative >ItemStateManager(s)? >* Does using XA cause more locking? > >Thanks in advance, >Regards, >Shaun -----Ursprüngliche Nachricht----- Von: Jukka Zitting [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 25. Juni 2008 12:45 An: dev@jackrabbit.apache.org Betreff: The concurrent library (Re: Locking issues with XAItemStateManager - help appreciated) Hi, [Moving the thread to [EMAIL PROTECTED] On Wed, Jun 25, 2008 at 1:31 PM, sbarriba <[EMAIL PROTECTED]> wrote: > ...and as an aside I note from > http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html > That concurrent 1.3.4 is now in maintenance mode. > Is there a plan to move to java.util.concurrent within the JDK? Jackrabbit is currently (mostly) based on Java 1.4, that doesn't yet have the java.util.concurrent library. There's the backport-util-concurrent library [1] that we could (should?) migrate to before upgrading to Java 5. However, last time I checked the required Jackrabbit modifications are not trivial (some of the classes and semantics in concurrent 1.3.4 are different from java.util.concurrent) so unless someone wants to scratch that itch and provide a good patch for this I'm inclined to stick with the what we have now. [1] http://backport-jsr166.sourceforge.net/ BR, Jukka Zitting
