The following issue has been updated:
Updater: Gianny DAMOUR (mailto:[EMAIL PROTECTED])
Date: Thu, 2 Oct 2003 5:24 AM
Comment:
Not part of the patch. It is a MBean which can be deployed by a running server
in order to test the Connection Management implementation.
More accurately, for an Oracle test:
- download the JDBC connector RI, from here
http://java.sun.com/products/jdbc/related.html;
- unpack the spi_15_ds.rar JDBC connector in a folder, e.g. myTest;
- configure the DD myTest/META-INF/ra.xml;
- add classes12.jar to myTest;
- drop myTest in the deploy directory.
At this stage if the ConnectorDeploymentPlanner is up - service mounted by
ConnectorDeploymentPlanner-service.xml - the JDBC connector is deployed.
Now, drop testerCM-service.xml in the deploy directory. An MBean having the
name geronimo.test:role=tester,name=TesterCM is registered. Use the load
operation of this MBean.
Changes:
Attachment changed to patch-ConnectionManagement-test.jar
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-97&page=history
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: Apache Geronimo
Components:
core
Assignee:
Reporter: Gianny DAMOUR
Created: Thu, 2 Oct 2003 5:10 AM
Updated: Thu, 2 Oct 2003 5:24 AM
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
