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 <[email protected]> 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
