jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Dreisiebner" <norbert.dreisieb...@hms.org>
Subject AW: dangling connections on JBoss
Date Mon, 15 Oct 2007 09:43:56 GMT
Hi Alexander!

I also experienced the same problems like you using the jackrabbit jca connector.

When using jackrabbit 1.3.1 there is a workaround regarding the first issue: add <track-connection-by-tx/>
to your jackrabbit ds. That should make your transactions work without REQUIRES_NEW.

The by far better solution imho is to upgrade to jackrabbit 1.3.3 where this bug (JCR-1109)
seems to be resolved.

Moving on to the second problem I think that you have to logout from your sessions manually.
Currently I do this the following way:

public someMethod() {

	// aquire your jcr session here
	Session session = .....

	try {

		// do your business stuff....

	} finally {

		session.logout();
	}
}

Doing so, you won't run out of transaction connections.


That's the way things are running now... but I just cannot believe that that's the best approach.
Isn't the creation of a jcr session object within each method call a huge performance overhead?

Using jackrabbit 1.3.3 the session object now also works as simple member variable that is
instantiated at bean construction - but only if I set property "bindSessionToTransaction"
in jackrabbit ds to false, otherwise I get a "Inactive logical session handle called" exception.

The problem is that in this case the transaction handling doesn't work as expected... (e.g.
data is stored even if transaction is set to roll back) so it seems that there's no way around
instantiating the session object within every single method call..... any ideas? :)

Best regards
Norbert D




-----Urspr√ľngliche Nachricht-----
Von: Foo Bar [mailto:mittspamkonto@gmail.com] 
Gesendet: Samstag, 13. Oktober 2007 03:23
An: users@jackrabbit.apache.org
Betreff: dangling connections on JBoss

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 14.10.2007 09:22
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 14.10.2007 09:22
 

Mime
View raw message