You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Cory Prowse <co...@prowse.com> on 2010/10/12 10:14:34 UTC

Auto-commit true in JCA (was Re: Transaction "TX_0" not found on first repository access)

Hi,

I've been looking into the exception thrown upon the first access to Jackrabbit when deployed as JCA.

What I believe is the root cause is that the ConnectionRecoveryManager always enables auto-commit, causing any distributed transactions to fail (since the two phase commit can't work since it is already auto commited).

So, does the ConnectionRecoveryManager need to enable auto-commit?
Can auto-commit be forced to always be disabled when Jackrabbit is deployed using JCA?

 -- Cory


On 11/10/2010, at 5:47 PM, Cory Prowse wrote:

> Hi,
> 
> I'm attempting to deploy Jackrabbit using the JCA deployment and seeing an error about an unknown transaction "TX_0" upon first access to the Repository.
> 
> I am deploying to Glassfish 3.0.1 and using H2 as the database.
> This is with Jackrabbit 2.1.1, however I also checked out the latest trunk and attempted to use a build from that but it seems broken at the moment.
> 
> The error is:
> javax.transaction.xa.XAException: Transaction "TX_0" not found; SQL statement:
> COMMIT TRANSACTION TX_0 [90129-142]
> 
> After digging through the running code, I discovered it was being thrown from the XaSessionImpl.commit() method.
> The same XID is passed into all methods, and the order of calls to XASessionImpl is:
> 1. start
> 2. end
> 3. prepare
> 4. commit - (note: the parameter onephase is false so no prepare is called inside this method)
> 
> Also note that although the first usage is not a onephase transaction, future calls are and there are no calls to XASessionImpl.prepare().
> 
> Can anyone shed some more light on this issue?
> I'm worried that Jackrabbit isn't initialising itself correctly on startup?
> 
> -- Cory

Re: Auto-commit true in JCA (was Re: Transaction "TX_0" not found on first repository access)

Posted by Cory Prowse <co...@prowse.com>.
Ahh.. ok replacing the config with all defaults works:

<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.H2PersistenceManager">
	<param name="schemaObjectPrefix" value="${wsp.name}_" />
</PersistenceManager>

Thank you Jukka, the world makes a little more sense again,

 -- Cory

On 12/10/2010, at 7:52 PM, Cory Prowse wrote:

> Firstly thankyou for the quick responses, I really appreciate it!
> 
> I'm not sure, the persistence manager config I am using is:
> 
> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.H2PersistenceManager">
> 	<param name="driver" value="javax.naming.InitialContext" />
> 	<param name="url" value="jndi:jdbc/Workspaces" />
> 	<param name="schema" value="h2" />
> 	<param name="schemaObjectPrefix" value="${wsp.name}_" />
> </PersistenceManager>
> 
> This JNDI resource is only used by Jackrabbit as above, I am not accessing it myself in any way.
> (from debugging through a running system I believe that the container enlists the Jackrabbit JNDI resource on the first access and in doing so causing the workspace to be built).
> 
> Does this mean I should not use a JNDI datasource?  (which I have created a jdbc connection pool for).
> 
> -- Cory
> 
> On 12/10/2010, at 7:23 PM, Jukka Zitting wrote:
> 
>> Hi,
>> 
>> On Tue, Oct 12, 2010 at 10:14 AM, Cory Prowse <co...@prowse.com> wrote:
>>> What I believe is the root cause is that the ConnectionRecoveryManager always
>>> enables auto-commit, causing any distributed transactions to fail (since the two
>>> phase commit can't work since it is already auto commited).
>> 
>> Let me guess, you've configured Jackrabbit to use an underlying
>> database connection that's also a part of the distributed transaction?
>> That's not supported. Jackrabbit implements XA support directly on the
>> JCR Session level, and to do so it requires full control of any
>> underlying database connections.
>> 
>> To implement the XA commit() contract Jackrabbit needs to know that
>> when it does commit changes to the underlying database (through
>> auto-commit where appropriate), those changes actually get written to
>> disk instead of being left waiting for a distributed transaction to
>> complete.
>> 
>> BR,
>> 
>> Jukka Zitting
>

Re: Auto-commit true in JCA (was Re: Transaction "TX_0" not found on first repository access)

Posted by Cory Prowse <co...@prowse.com>.
Firstly thankyou for the quick responses, I really appreciate it!

I'm not sure, the persistence manager config I am using is:

<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.H2PersistenceManager">
	<param name="driver" value="javax.naming.InitialContext" />
	<param name="url" value="jndi:jdbc/Workspaces" />
	<param name="schema" value="h2" />
	<param name="schemaObjectPrefix" value="${wsp.name}_" />
</PersistenceManager>

This JNDI resource is only used by Jackrabbit as above, I am not accessing it myself in any way.
(from debugging through a running system I believe that the container enlists the Jackrabbit JNDI resource on the first access and in doing so causing the workspace to be built).

Does this mean I should not use a JNDI datasource?  (which I have created a jdbc connection pool for).

 -- Cory

On 12/10/2010, at 7:23 PM, Jukka Zitting wrote:

> Hi,
> 
> On Tue, Oct 12, 2010 at 10:14 AM, Cory Prowse <co...@prowse.com> wrote:
>> What I believe is the root cause is that the ConnectionRecoveryManager always
>> enables auto-commit, causing any distributed transactions to fail (since the two
>> phase commit can't work since it is already auto commited).
> 
> Let me guess, you've configured Jackrabbit to use an underlying
> database connection that's also a part of the distributed transaction?
> That's not supported. Jackrabbit implements XA support directly on the
> JCR Session level, and to do so it requires full control of any
> underlying database connections.
> 
> To implement the XA commit() contract Jackrabbit needs to know that
> when it does commit changes to the underlying database (through
> auto-commit where appropriate), those changes actually get written to
> disk instead of being left waiting for a distributed transaction to
> complete.
> 
> BR,
> 
> Jukka Zitting

Re: Auto-commit true in JCA (was Re: Transaction "TX_0" not found on first repository access)

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Tue, Oct 12, 2010 at 10:14 AM, Cory Prowse <co...@prowse.com> wrote:
> What I believe is the root cause is that the ConnectionRecoveryManager always
> enables auto-commit, causing any distributed transactions to fail (since the two
> phase commit can't work since it is already auto commited).

Let me guess, you've configured Jackrabbit to use an underlying
database connection that's also a part of the distributed transaction?
That's not supported. Jackrabbit implements XA support directly on the
JCR Session level, and to do so it requires full control of any
underlying database connections.

To implement the XA commit() contract Jackrabbit needs to know that
when it does commit changes to the underlying database (through
auto-commit where appropriate), those changes actually get written to
disk instead of being left waiting for a distributed transaction to
complete.

BR,

Jukka Zitting