On Nov 23, 2005, at 1:36 PM, [EMAIL PROTECTED] 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:
http://svn.apache.org/repos/asf/geronimo/trunk/modules/transaction/
src/java/org/apache/geronimo/transaction/manager/
TransactionManagerImplGBean.java
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.
thanks
david jencks
David Jencks <[EMAIL PROTECTED]>
11/23/2005 12:10 PM
Please respond to user
To: [EMAIL PROTECTED]
cc:
Subject: Re: Enlisting XAResource objects
On Nov 23, 2005, at 11:54 AM, [EMAIL PROTECTED] 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.
*****************************************************************
