Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <4292421B.5010706@rutgers.edu>
References: <20050523191525.88851.qmail@web25108.mail.ukl.yahoo.com>
 <14f70bcd27e0360d4722bd1685ccf14f@gluecode.com>
 <42923AF1.9050803@rutgers.edu>
 <5bc98ddfbad08faa1e0d760e65cd9a25@gluecode.com>
 <4292421B.5010706@rutgers.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <aeef7aea5aabbb2d76f876ab3b908759@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: Integration of Geronimo modules (Tx / JCA) in Spring
Date: Mon, 23 May 2005 14:38:09 -0700
To: dev@geronimo.apache.org


On May 23, 2005, at 1:50 PM, Dmitriy Kopylenko wrote:

>
>>
>> I'm not sure what XAPool is.  Our strategy for jdbc, both  xa and 
>> non-xa, is to wrap the driver into a j2ca connector and deploy that 
>> in the j2ca framework.  There are several such j2ca-jdbc wrappers: 
>> the  one we are using (we wrote it) is at the tranql project at 
>> codehaus under connector.  By default it only wraps non-xa drivers. 
>> There's also a (probably broken by now due to lack of updates) oracle 
>> specific adaptation.  We also have a derby-specific xa wrapper inside 
>> geronimo.
>>
> The XAPool is a standalone connection pool for XA-capable datasources: 
> http://forge.objectweb.org/projects/xapool/  I'm familiar with that, 
> so may be Thierry, Juergen could comment on that. So instead of using 
> XAPool, we should really be looking at using (and therefore 
> configuring everything) Geronimo's tranQL based XA-capable pool...

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:
>> cvs.tranql.codehaus.org:/home/projects/tranql/scm
>>
>> 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 :-)
>>
>