geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Enlisting XAResource objects
Date Wed, 23 Nov 2005 22:02:48 GMT

On Nov 23, 2005, at 1:36 PM, wrote:

> The XAResource in question is a XA-capable write-back cache. So the  
> connection metaphor
> is not such a good fit - that's why I am asking the question.
> I would prefer to just grab a reference to the transaction manager  
> gbean, which implements
> javax.transaction.TransactionManager
> and call
> getTransaction().enlistResource(..)
> If I go with this solution, how to get a reference to the the  
> transaction manager gbean?
> Alternatively, I see the method watchResourceManagers here:
> src/java/org/apache/geronimo/transaction/manager/ 
> How would I write a gbean which ends up in this collection? Come to  
> think of it, this may be the way to go
> because I see that that will cause XAResource.recover() to be invoked  
> first.

I was going to mention that :-).  You still haven't told me how your  
(presumably j2ee) application finds the part of the RM to talk to.   
This could be an important part of the picture :-).

Without knowing that, I'd recommend writing a gbean (surprised?).  It  
should have a gbean reference to the TransactionmanagerImpl gbean.  You  
can also use the TransactionContextManager gbean which is a more  
geronimo-centric idea that deals with TransactionContexts that you  
might be able to store stuff in.

To use the recovery features you should do three things:

1. make sure your gbean's object name matches the patterns for the  
ResourceManagers reference.

2. make sure your gbean implmentation class implements ResourceManager

3. wrap your XAResource so it implements NamedXAResource.  We generally  
use the ObjectName/GBeanName of the component as the xa resource name.

re. the NamedXAResource, we record the name of the xaresource with the  
xid in the transaction log, so we can among other things determine  
during recovery when the resource managers involved in a transaction  
have all started so the transaction is recoverable.  I can't figure any  
way to determine that all RMs have started before starting the TM, so  
we just recover what we can when we can.  I believe JOTM/HOWL is using  
a similar scheme but I don't know the details.

This leaves the question of either how the gbean connects to the cache  
or how your application connects to the gbean.

Recovery is not well tested, but I will definitely help you with  
problems you encounter.

david jencks

> David Jencks <>
> 11/23/2005 12:10 PM
> Please respond to user
>         To:
>         cc:        
>         Subject:        Re: Enlisting XAResource objects
>  On Nov 23, 2005, at 11:54 AM, wrote:
>  >
>  > I have a home-grown resource manager (XAResource implementation)  
> which
>  > I would like enlist in a transaction.
>  > I see two ways of doing this:
>  >
>  > 1) Write a JCA resource adapter, since the app server has to enlist
>  > the xa resource for the connection.
>  >
>  > 2) Create a geronimo "configuration" which has a reference to the
>  > transaction manager gbean, then grab
>  > the javax.transaction.Transaction object from that and call the
>  > enlist- method.
>  >
>  > Does anybody care to comment on 1 vs. 2 ?
>  It's hard to judge without knowing more about what your RM actually
>  does.  If it has anything resembling connections that would be helped
>  with a connection pool, I would strongly recommend writing a resource
>  adapter.  Its pretty easy, you can base it on tranql-connector code,
>  etc etc and it will save you a lot of work trying to relate to the TM
>  properly.  If it really doesn't have anything like connections, then I
>  don't think it makes sense to write a RA.  In this case before I start
>  giving advice I'd like to know more about how your application gets in
>  touch with the RM and tells it to do something and how you envisage
>  enlist/delist to work.
>  thanks
>  david jencks
>  *****************************************************************
>  <<>>
>  In compliance with applicable rules and regulations, Instinet
>  reviews and archives incoming and outgoing email communications,
>  copies of which may be produced at the request of regulators.
>  This message is intended only for the personal and confidential
>  use of the recipients named above. If the reader of this email
>  is not the intended recipient, you have received this email in
>  error and any review, dissemination, distribution or copying is
>  strictly prohibited. If you have received this email in error,
>  please notify the sender immediately by return email and
>  permanently delete the copy you received.
>  Instinet accepts no liability for any content contained in the
>  email, or any errors or omissions arising as a result of email
>  transmission. Any opinions contained in this email constitute
>  the sender's best judgment at this time and are subject to change
>  without notice. Instinet does not make recommendations of a
>  particular security and the information contained in this email
>  should not be considered as a recommendation, an offer or a
>  solicitation of an offer to buy and sell securities.
>  *****************************************************************

View raw message