geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Borges <franci...@x-hive.com>
Subject Re: allocating Connection using ConnectionRequestInfo: failure testing
Date Tue, 10 Jul 2007 09:27:07 GMT
On Monday 09 July 2007, David Jencks wrote:
> I imagine problems with your connection factory would be easy for you
> and impossible for us to figure out, so I'll assume the problem is
> after that.
>
> Can you do some debugging or logging and check that your CRI is
> getting to the MCF

Short answer: CRI does not make to the MCF. See below.

>      javax.resource.spi.ManagedConnection createManagedConnection
> (javax.security.auth.Subject subject,
> javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
> throws javax.resource.ResourceException;
>
>      javax.resource.spi.ManagedConnection matchManagedConnections
> (java.util.Set set, javax.security.auth.Subject subject,
> javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
> throws javax.resource.ResourceException;
>
> methods as expected and that your MCF is throwing an exception?  This
> would help a lot in investigating what is going on.

Set up of my test is:

Pass CRI with the wrong values (unexisting DB, unexisting user etc) to

import javax.resource.cci.Connection;
import javax.resource.spi.ConnectionRequestInfo;
[...]
(Connection)connectionManager.allocateConnection(xhiveManagedConnectionFactory, 
        (ConnectionRequestInfo) connectionSpec);

                                                  ========
JBoss (4.2.0) will:

1. Call
class ManagedConnectionFactory {
ManagedConnection matchManagedConnections(
       java.util.Set set, 
       javax.security.auth.Subject subject,
       javax.resource.spi.ConnectionRequestInfo connectionRequestInfo) 
throws ResourceException 

Which fails to match, deletes an unmatched connection, and returns null;

2. Call 
Class ManagedConnectionFactory {
ManagedConnection createManagedConnection(Subject, ConnectionRequestInfo)

Where an exception is thrown due to the wrong parameters.

                                                 =========

On Geronimo, the code never reaches neither createManagedConnection nor 
matchManagedConnections, and I get the pre-existing (valid) connection 
back. 

Could Geronimo be using the pool with  <select-one-assume-match/>
despite the fact that I have <match-all/> in the pool configuration at 
geronimo-ra.xml?

Is there somewhere else, in my code, I should be looking at? 

> BTW I think you want match-all if you want to use one pool, unless
> the match method can change the CRI info in an existing connection.
> The idea behind multiple pools is that you can divide the connections
> up by the match criteria so that matches will always succeed and you
> only need to supply one MC to match.  Otherwise match is likely to
> fail with distinct CRIs and the pool will start killing connections
> for you.

Thank you for pointing this out. 

I was using "match-all" but started trying different things, to see if the 
problem was not at the pool deployment. As getting the valid connection 
back, made me think Geronimo was somehow using looked as if the pool

I decided to use single-pool based on the "tip" at the pool configuration 
here 
<http://chariotsolutions.com/geronimo/geronimo-1.1/connector-plan.html>, 
I guess I need to ask people which is the typical usage case.

Thanks a lot for the attention and insightful comments, 

Cheers,
-- 
Francisco Borges

Mime
View raw message