[jira] Commented: (GERONIMO-97) JCA - Connection Management

[ji...@codehaus.org]

The following comment has been added to this issue:

     Author: David Jencks
    Created: Mon, 6 Oct 2003 6:51 PM
       Body:
I've spent some time looking at the ConnectionManager part of this code, and I'm not very happy with it.  I'm having a very hard time understanding how the classes fit together and where any of the actual work occurs.

Two architectural decisions I disagree with are:
1. number of ConnectionManager instances.  I think it makes most sense to have a ConnectionManager for each deployed ManagedConnectionFactory.
2. structure of interceptor stack for a ConnectionManager implementation.  If I understand the design correctly, the interceptor class called Partition, and has multiple children.  Each interceptor is responsible for deciding which child to delegate to.  While this is a very powerful class model or meta-pattern, I don't think it is appropriate here.  IMO a ConnectionManager for a single ManagedConnectionFactory/ConnectionFactory should have a single stack of interceptors each of which can perform inverse operations for getting and returning a connection.  If an interceptor cannot finish the request, it delegates to the single next interceptor, without knowing what it is.

If I've misunderstood your design, please let me know.

I'm going to attach the preliminary implementation of interceptors I've been working on.  My implementation is extremely incomplete (for instance it lacks a pooling interceptor) but does include some transaction management and illustrates my idea for an interceptor implementation.

On another front, I think it is a good idea to deploy the ResourceAdapter and ManagedConnectionFactory as mbeans so their properties are directly accessible via jmx.
---------------------------------------------------------------------
View the issue:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-97


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GERONIMO-97
    Summary: JCA - Connection Management
       Type: New Feature

     Status: Assigned
   Priority: Major

 Time Spent: Unknown
  Remaining: Unknown

    Project: Apache Geronimo
 Components: 
             core

   Assignee: David Jencks
   Reporter: Gianny DAMOUR

    Created: Thu, 2 Oct 2003 5:10 AM
    Updated: Mon, 6 Oct 2003 6:34 PM

Description:
This is the final proposal for the Connection Management section of the JCA specifications. It is a "clean" version of GERONIMO-90 + a minimalist deployer which allows to test such an implementation within a running server.

When I write "clean", it is evident that some works still need to be done, however based on the size of the code-base - 30 classes - it should be great to reflect seriously on this proposal.

The content by package is:

*********************************************************
org.apache.geronimo.connector.connection:
*********************************************************
The ConnectionManager spi interface has been implemented and delegates the allocation of connection handles to a pool of ManagedConnection. By now, the ConnectionManager is really simple: it delegates directly to the pool. However, one needs to hook-in the Transaction and Security services in the allocateConnection method.

*********************************************************
org.apache.geronimo.connector.connection.partition:
*********************************************************
The specifications do not define how connection pooling should be implemented. However, some non-prescriptive guidelines have been provided. One of them is to partition this pool. This is basically what I have decided to implement: The pool is partition on a per-ManagedConnectionFactory basis. By now, it is further partitioned on an idle, active, factory, destroy basis. The general idea of this design is to define distinct set of behaviors depending on the kind of partition. 

Examples: 
The factory partition is in charge of creating/allocating new connection handles. When its allocateConnection method is called, it decides if a new ManagedConnection should be created or if an existing one can be re-used. 
The XA partition (to be implemented) is in charge of creating/allocating new transacted connection handles. When its allocateConnection is called, it enlists the ManagedConnection with our TM and then gets a connection handle from this enlisted ManagedConnection. 

Inter-partition events can be propagated via an AWT like event model. This mechanism is used for example by the factory partition: It monitors the idle and destroy partitions in order to decide how to serve a new allocation request. More accurately, if a ManagedConnection is added to the idle partition, then a permit to try a matchManagedConnection is added. If a ManagedConnection is added to the destroy partition, then a permit to create a new ManagedConnection is added. 

*********************************************************
org.apache.geronimo.connector.connection.recycler:
*********************************************************
Partitions may be recycled. For instance, if a ManagedConnection seats idle too long time, then this ManagedConnection may be eligible for recycling (destroy in the case of idle ManagedConnection).


*********************************************************
org.apache.geronimo.connector.connection.logging:
*********************************************************
The inner workings of ManagedConnectionFactory and ManagedConnection can be tracked via a PrintWriter. LoggerFactory defines the contract to obtain a PrintWriter factory backed by various output streams. 

*********************************************************
org.apache.geronimo.connector.deploy:
*********************************************************
A minimalist deployer for the outbound-resourceadapter nodes is implemented.

Gianny


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira