Check this out:
http://th1rty7.blogspot.com/2009/03/spring-distributed-transactions-across.html

On Wed, May 27, 2009 at 3:39 PM, Peter Henzler <[email protected]> wrote:
> Hi Jukka
>
> Thank you for the reply.
>
>> The sessions you get from the Repository.login() method from
>> Jackrabbit implement the org.apache.jackrabbit.api.XASession
>> interface, whose getXAResource() method can be used to attach the
>> session to a distributed XA transaction.
>
>> The nice thing about the JCA packaging is that it handles the
>> XAResource part automatically for you, but there's nothing stopping
>> you from doing the same with a little bit of code also in other
>> deployment scenarios.
>
> Do you mean code like this?:
>
>        Transaction tx = tm.getTransaction(); // get the running 
> javax.transaction.Transaction
>        XASession session = (XASession)repository.login(creds, rename);
>        XAResource res = session.getXAResource();
>      tx.enlistResource(res);
>        // do changes in repository through the session interface
>      session.logout();
>      tx.delistResource(res, XAResource.TMSUCCESS);
>
> Or what code do you mean?
>
> Would that be enough for committing the repository changes when the global 
> container managed XA Transaction with changes of other database connections 
> get commited or to get rollbacked if one of those others throws an exeption?
>
>
>
>
>
>>> If I am using the Jackrabbit Datastore and Persistence configured with an XA
>>> JDBC-Driver, do I really need Transactions in Jackrabbit. Wouldn't the XA
>>> JDBC-Driver work in a 2phase commit handled by the installed JTA
>>> TransactionManager ?
>
>>No. Jackrabbit expects to be in full control of the underlying
>>database connection, so having it included in an externally managed
>>transaction is not a good idea. We've seen quite a few problems caused
>>by this.
>
> Ok, I unterstand that Jackrabbit want it's own database connection that is 
> not used by anyone else.
> You mean that the configured JDBC Driver for the Jackrabbit repository should 
> be a normal JDBC Driver instead of a XA JDBC Driver?
>
> Best regards
> Peter
>



-- 
sp

Reply via email to