Aaron, 
yes sounds like a solid standard pool you've got there.  Integrating it
in JMX is fairly orthogonal from integrating it in jBoss 2.0.  Rickard
will be waking up in a few hours and will probably give you good
directions on modules.  But in the mean time I would like to draw your
attention to 2 things.

1- It will need a minor integration in EJX to be configurable (choose
this pool or not)
2- It will need to be integrated Tx wise.  

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).

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
level of integration with the underlying JTS-derivative provider) or if
it falls on the container in which case bean requested (BMP) connections
can bypass some of that (Still go through JNDI's JNP so we could catch
that).

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, ;-)

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");

// Is there a running transaction associated with the thread?
Transaction tx = txMan.getTransaction();

if (tx != null) {
 
    // create a XA wrapper for it
    YourXARessourceWrapper xaRessource = new
YourXARessourceWrapper(connection);
    
    // Register the wrapper with the transaction monitor
    ((TransactionImpl) tx).enlistResource(xaResource);

}

// done

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.

just a heads up
regards

marc


Aaron Mulder wrote:
> 
>         Well, I spent some time looking through the JMX spec and code.
> Whew!  Dense stuff.
>         I guess I should explain what I've got.  It's a JDBC connection
> pool architecture implemented as a JDBC driver.  That is, you initialize
> one or more connection pools (read settings out of a configuration file or
> something - including the JDBC URL that the pool should use to create
> connections form the underlying DB). Then when you want to get a
> connection from the pool, you use the usual DriverManager routine with a
> URL like jdbc:pool:poolname.  If there's a loose connection in the pool,
> you get it.  Otherwise, it uses the preconfigured parameters to open a new
> physical connection and puts it in the pool.  When you call close on the
> connection, it gets marked as free in the pool (it isn't really closed).
>         So the use of the connections would already fit in the
> orb.jboss.jdbc.DataSourceImpl - you'd just give the pool's URL to the
> DataSourceImpl in an <MLET> entry.  This would unfortunately result in
> double-pooling with the current DataSourceImpl implementation, but that's
> a minor change.
>         Yhere are two loose ends here.  The first is how to initialize the
> pool.  We could create a JMX helper class so you include an MLET tag in
> the config file with the pool parameters, and the helper class will just
> initialize the pool.  The other problem is how to shut down the pool - but
> I guess this could be done the same way.
> 
>         Does that sound like the right track?  Will you be willing to drop
> the pooling in the DataSourceImpl to work with this, or should I implement
> a different data source or something?
> 
>         Finally, how should I get code to you?  Post it here?  There are
> ~10 classes (including JDBC wrappers to update "last used" times, etc.).
> 
> Thanks,
>         Aaron
> 
> On Fri, 19 May 2000, marc fleury wrote:
> > Do it in a plugin (I forgot to say)
> >
> > marc

-- 

----------------------------------------------------------------
Visit Telkel at JavaOne(SM), Sun's 2000 Worldwide Java Developer
Conference(SM)
June 5-9, 2000 - Moscone Center - San Francisco

Reply via email to