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