Hi!

I'm using JBoss 4.2.1GA and jackrabbit 1.3.1, with JCA connector 1.3.1. My config is as follows:

<pre> <tx-connection-factory> <jndi-name>jcr/local</jndi-name> <xa-transaction/> <rar-name>convertfrontend-1.0-SNAPSHOT.ear#jackrabbit-jca.rar</rar-name> <connection-definition>javax.jcr.Repository</connection-definition> <config-property name="homeDir" type="java.lang.String">/var/mediastorage/jcrstore</config-property> <config-property name="configFile" type="java.lang.String">classpath:repository.xml</config-property> <config-property name="bindSessionToTransaction" type="java.lang.Boolean">true</config-property> </tx-connection-factory> </pre>

My first issue was that I was experiencing the two-sessions per transaction deadlock, for no apparent reason (used one transaction and one session). This made me to use REQUIRES_NEW transaction attributes on all jackrabbit save operations, which surprisingly helped getting rid of the deadlock. Anyway, now that I've done that, it still seems like jackrabbit is not really logging out sessions, since I run out of transaction connections after exactly 20 fetches (reproducable):

<pre> java.lang.RuntimeException: Error initializing JCR access:javax.jcr.RepositoryException: No ManagedConnections available within configured blocking timeout ( 30000 [ms] ): No ManagedConnections available within configured blocking timeout ( 30000 [ms] ) </pre>

I also get some warnings before this happens:

<pre> [org.jboss.resource.connectionmanager.CachedConnectionManager] Could not find a close method on alleged connection objects. Please close your own connections. </pre>

I have an alternative storage implementation using java.io, and I have no such problems when I switch to that solution, so I beleive that the problem is from within jackrabbit.

My theory is that the sessions never get commited. The first workaround with the double sessions convinced me, since I was calling different session beans from a server, with no more than one jcr session in each method call. The fact that the multiple session bug was visible in this situation should indicate that the session must survive the transaction and still be attached to the current thread even after the transaction has ended.

This theory also seems logical with respect to the fact that everything started to work after REQUIRES_NEW, but that I ran out of threads.

Is there anything that I have missed to do in order to be sure that sessions get closed at the end of each transaction? Do I need to do a session logout programmatically? Does anyone have any suggestion as to what I should do to make this work? Any help is greatly appriciated.

I've searched the mailing list, and found a couple of similar issues, with no answers:
http://article.gmane.org/gmane.comp.apache.jackrabbit.user/979/match=blocking+timeout
http://article.gmane.org/gmane.comp.apache.jackrabbit.user/637/match=blocking+timeout

Best Regards

/Alexander T