Hey
This is gonna be great :-)
marc fleury wrote:
> 1- It will need a minor integration in EJX to be configurable (choose
> this pool or not)
Not really. You can already configure which JNDI-name a
ResourceReference should point to, so it's not dependent in which
implementation is used. All you have to do is replace the DataSourceImpl
and bind it in JNDI.
> 2- It will need to be integrated Tx wise.
Absalutaly.
> When a Pool manager returns a connection that connection can be enrolled
> in a global transaction (JTA) running in the application. The
> demarcation on that transaction is what drives the 2 phase commits that
> would include this XARessource. All that needs to happen is that somehow
> the container (container including your pool) enrolls the connection
> with the Transaction manager before returning it (check that tx is
> running, enroll if yes ;0).
Note: *if* a connection is enrolled in a tx, then the next getConnection
call *must* return that same connection, so you need to keep a hashtable
(tx->con) to keep track of which connections are tied up in tx's.
(hm...... now that I think of it it doesn't *have* to be the same
connection, but rather you need to call start() and end() at appropriate
times (start() when you acquire the con, end() when you put it back into
the pool). Should work.. wow, why didn't I think of that before.. silly
me..)
> In jBoss 1.0 we used the JOnAS Tx and pool management because this was
> automatically taken care of. I don't know how it is done and more
> precisely where it is done, in jBoss 2.0 and specifically I don't know
> if it falls on the plugin to do so (in which case there is a certain
It does. The current plugin is not integrated with tx's.
> I just checked Rickard's "TransactionImpl"
> (org.jboss.tm.TransactionImpl) and he does have a
> enlistResource(XAResource)
> as well a ThreadLocal tx.getTransaction() that returns whether you are
> running a current transaction (geezus kid I though we were relying on
> the thread.contextClassLoader thingy to hold Tx , ts-ts, ;-)
Associating tx's with the contextClassLoader would only work if we had
one CL/thread, which we don't. So it wouldn't work. (ahem, which was the
result of the tx-thread-cl discussion awhile back, remember? ;-)
> In short you just need to do
>
> //get the Transaction manager (no static in TxManager, so JNDI lookup I
> guess?)
> TxManager txMan = (TxManager) new InitialCOntext().lookup("theTxMan");
The TxManager doesn't have any state currently, so all you have to do is
new TxManager(). But I could easily do a JMX MBean which instantiates
and binds one into JNDI. That might be a cleaner way to get to it.
> // Is there a running transaction associated with the thread?
> Transaction tx = txMan.getTransaction();
>
> if (tx != null) {
Tx is never null. If a tx is not started then it simply returns
STATUS_NO_TRANSACTION on getStatus().
>
> // create a XA wrapper for it
> YourXARessourceWrapper xaRessource = new
> YourXARessourceWrapper(connection);
>
> // Register the wrapper with the transaction monitor
> ((TransactionImpl) tx).enlistResource(xaResource);
>
> }
>
> // done
You also need to (as noted above) call start/end on the connections
XAResource.
> return connection;
>
> This before you return the connection from your pool
> when a connection returns, well you figure it out;-)
> it's a bit more complicated depending on the status.
Aaron, ask me if you have any more questions. And Marc: you should read
the JTA spec one more time ;-) (although I don't blame you; I just
understood these things myself)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
