usage of matchManagedConnections
aquaas Aug 19, 2002 9:07 AMHi,
I have two remarks regarding the usage of the matchManagedConnections methods in the ManagedConnectionFactory interface in JBoss-3.0.0.
The j2ee connector spec (1.0) says the following about this method (on page 29):
If the resource adapter cannot find an acceptable ManagedConnection instance, it returns a
null. In this case, the application server requests the resource adapter to create a new connection
instance.
As far as I can see the matchManagedConnection method is only used from the InternalManagedConnectionPool class, in the following code:
mc = mcf.matchManagedConnections(new SetOfOne(mc), subject, cri);
if (mc == null)
{
//match didn't work!
throw new ResourceException("Error in use of ManagedConnectionPool: matchManagedConnection failed with subject: "+ subject + " and ConnectionRequestInfo: " + cri);
} // end of if ()
Now according to my interpretation of the spec(and its consequences) there are two things wrong with the code above:
- If matchManagedConnections returns null then a new managedconnection should be created instead of throwing an exception
- Instead of supplying one managed connection all the managedconnections in the pool should be supplied so matchManagedConnection can pick a connection that matches the requested criteria.
Currently users will run in problems if they request connections with different parameters(for instance different usernames/passwords) in the connectionrequestinfo object, and if the resource adapter uses this parameters to determine if a connection matches(which seems to be the most logical thing to do).
The behavior is also undetermenistic from a users point of view because if the pool is empty (no connections available in pool) the request of a connections with different parameters will succeed since a new connection is then created.
Another thing is that if the matchManagedConnections method returns null the managedconnection is not returned the pool, and is lost for usage.
Can somebody verify my findings, and maybe give some more explanation. One reason I can imagine for the current implementation is that it would require a lock on the complete pool if the complete pool would be passed to the matchManagedConnections method, and creating a new connection if none matches could let the pool grow to fast. But both reasons introduce new problems.
Thanks in advance
Arno de Quaasteniet
X-Hive Corporation
+31 (0)10 710 86 24
http://www.x-hive.com
arno@x-hive.com