geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Integration of Geronimo modules (Tx / JCA) in Spring
Date Tue, 24 May 2005 19:34:16 GMT

On May 24, 2005, at 1:23 AM, Thierry Templier wrote:

> Thanks a lot David!
> I'll take a look at Tranql and the derby xa wrapper...
> Have you seen the code to initialize the Geronimo
> TransactionManager and TransactionContextManager? Is
> it correct and what about the NullPointerException we
> have had in the ConnectionTrackingCoordinator class?

NPE -- see my explanation in my first reply, and ask more specific  
questions if what I wrote is incomprehensible :-)

TM initialization -- you should use the up to date code :-)

Hmm. looking at this a bit I see we are using the geronimo kernel  
automatic collection management to register the resource managers with  
the tm.  What kind of environment are you targeting?  Is this a static  
environment intended to run a single application, and restarted  
whenever anything changes, or is it an environment in which jca  
adapters/resource managers will be deployed and undeployed dynamically  
while the container is running?  With the current implementation you  
will need to figure out a way to implement ReferenceCollection so you  
can add all the jca adapters to it... or if you aren't interested in  
recovery just implement an empty ReferenceCollection.

ReferenceCollection resourceManagers = ??//don't know what you want to  
do here
TransactionLog transactionLog = new UnrecoverableLog();
ExtendedTransactionManager transactionManager = new  
TransactionManagerImpl(60, transactionLog, resourceManagers);

TransactionContextManager transactionContextManager = new  
TransactionContextManager(transactionManager, transactionManager);

If you are in spring, I'd think you could use spring wiring to assemble  
this -- we use gbeans to assemble it in geronimo.

Hope this helps
david jencks

> Thierry
>> I think that would be a good idea.  We don't really
>> have a generic xa
>> wrapper because you really want to expose the
>> XADatasource properties
>> as ManagedConnectionFactory properties.  This is
>> really easy to do,
>> however: see the derby xa wrapper in geronimo.
>> Since there aren't all
>> that many xa drivers, wrapping all of them may not
>> be an infinitely
>> large task.  We do have a generic Driver wrapper,
>> and the j2ca
>> framework deals just fine with local transaction
>> adapters.  (you don't
>> get xa semantics, but you don't get exceptions
>> either).
>> Remember also that the pooling code itself is inside
>> the
>> ConnectionManager implementation, thus in the
>> geronimo connector
>> module.
>> A couple other comments that might be a bit advanced
>> for now...
>> One other hidden tidbit you might be interested in
>> is, Jeremy figured
>> out how to make last-resource one phase commit
>> optimization actually
>> work with correct semantics if the last resource is
>> a database and it
>> is used for the transaction log.  There's an
>> untested implementation of
>> this in o.a.g.connector.outbound.transactionlog.  I
>> think it could be
>> useful when you want to use jms and a non-xa
>> database.
>> Also, the "bridge" stuff for container managed
>> security is probably a
>> bad idea and should be replaced by just putting more
>> login modules into
>> your original login configuration.
>> thanks!
>> david jencks
>>>> Here's part of the cvs connection string:
>>>> Generally each driver really should have a driver
>> specific class to
>>>> indicate which sql exceptions it throws mean that
>> a connection is
>>>> dead and should be discarded.  However, no one
>> has actually written
>>>> one of these yet :-)
> Take a look at my blog:
> _______________________________________________________________________ 
> ______
> Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos  
> mails, photos et vidéos !
> Créez votre Yahoo! Mail sur

View raw message