jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Foo Bar" <mittspamko...@gmail.com>
Subject Re: dangling connections on JBoss
Date Mon, 15 Oct 2007 13:35:14 GMT
2007/10/15, Norbert Dreisiebner <norbert.dreisiebner@hms.org>:
> Hi Alexander!

Hi Norbert!

>
> 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.

I thought this is what "bind session to transaction" did. If that is
not true, they seriously need to rename that variable :). I wonder
what is really going on here, maybe Jboss is passing objects between
threads, or starting new transactions in ways that the Jackrabbit
transaction manager does not anticipate?

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

I'm not sure that I have the same error. I get no stacktraces, seems
like a real deadlock to me. I have symptoms similar to those in
http://issues.apache.org/jira/browse/JCR-769

>
> 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.

If that fixes the problem, it would indicate that jackrabbit fails to
finalize its connection when the transaction ends

>
>
> 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?

Well, that depends on the number of calls per transaction, but
generally yes i guess. I'm not sure how jackrabbit integrates into the
JTA, but if session.logout break atomicity, then this is not really a
good idea. Its basically equal to REQUIRES_NEW, with the difference
that REQUIRES_NEW seems to commit, but still lock the thread :D

>
> 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.

Wow, that sounds really confusing. Does that mean that there's only
one session in jndi? Someone needs to clarify this.

>
> 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?
:)

Well, I'm not sure. Judging by all the examples on the wiki and this
discussion I would guess that the behaviour we're seeing is not
expected. Maybe someone could clarify this?

Good luck with your stuff, I'll post if I manage to get a working
solution. I have been unsuccessful with anything I've tried so far. I
even tried to create the session programmatically, but then i get
"repository seems to be locked to the current process". So im
basically in the situation when jackrabbit provides less than java.io.
It would be great to get atomicity working, there must be some sort of
incompability between jackrabbit and current JBoss.

>
> Best regards
> Norbert D
>


Regards

Alex
>
>
>
> -----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