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 <cory@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
>