2 Replies Latest reply on Aug 29, 2002 9:25 AM by aquaas

    usage of matchManagedConnections

    aquaas
    aquaas Aug 19, 2002 9:07 AM

      Hi,

      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

      • 5057 Views
      • Tags:
        • 1. Re: usage of matchManagedConnections
          davidjencks
          davidjencks Aug 20, 2002 1:03 PM (in response to aquaas)

          1. The pooling system is designed so that alternative pool implementations can be easily written and plugged in. I implemented what I thought would be most useful, but I know there will be needs for other possibilities.

          2. You are correct that I think that supplying more than one connection to the matchManagedConnection method will reduce concurrency too much.

          3. I expect that most adapters will use Subject and ConnectionRequestInfo to determine which managed connection is most appropriate. The pooling system is designed so that by setting the Criteria property you determine how the pool is divided up, and so the ManagedConnectionFactory will only get connections it will accept.

          4. Does your adapter rely on something other that Subject and ConnectionRequestInfo to determine if a connection matches? Please explain: I don't know of a circumstance where this would be appropriate, but I'm happy to learn. Do you think if match fails the pool should continue through the unused managedconnections trying to find one that matches?

            • Actions
          • 2. Re: usage of matchManagedConnections
            aquaas
            aquaas Aug 29, 2002 9:25 AM (in response to aquaas)

            Oops. I wasn't aware of the existence of the criteria attribute. I only use the connectionRequest and subject information so using the criteria attribute is sufficient for me. So the only one who'll be learning something here is me (should read the manual first), since I can not give you examples of other criteria.

            I think your last suggestion about continuing with other connections from the pool if the match fails would be a good idea if the possibility of having multiple pools didn't exist, but since it exists I think it will always be the preferred way to go because of its better performance.

              • Actions