Posts Tagged ‘ConnectionManager


Connection request flow on outbound JCA connector

Continuing with the posts about outbound JCA connectors lets have a quick look at one of the main flows of an outbound JCA connector: the connection request flow.

By now you might be wondering: “What on earth is responsible for making my connectors poolable? Is there any dark magic involved?”.

First answer: “the ConnectionManager” and second answer: “Yes and it is container dependant!”. That’s the reason you should keep an instance of the ConnectionManager inside your ConnectionFactory when it is created, that’s how you delegate the connection creation to the pooling implementation of the container.

Enough explanation let’s have a look on a sequence diagram for a connection creation when we have no connections inside the pool.

First flow: connection request with no matching connections

First thing to take note, it is up to you to implement the matchManagedConnections, I’ve put a note on the next diagram that might help on this implementation: making the ManagedConnection be able to compare itself to a ConnectionRequestInfo makes the things easier. Also beaware that some Application Servers (eg.: WebSphere) skip the matchManagedConnections part if it detects by itself that the pool is empty or there isn’t any matching connection.

Sequence Diagram - No Matching Connection

Sequence Diagram - No Matching Connection

Another point about the specification is that it states that a single managed connection may be responsible for more than a single physical connection (FooConnectionImpl), this is required for scenarios where connection sharing is possible (refer to section of the specification).

Previously I tried implementing using a single handle but I noticed that it does not take much effort to make it fully adherent, in fact, it is only necessary to use a delegate (FooConnectionHandle) that implements the FooConnection interface and delegates almost all the methods to the FooConnectionImpl instance that is inside the FooManagedConnection instance (refer to sections and 6.8.1 of the specifications). The exception to the delegation is the close method that your connection must provide, this method in the delegate will be responsible for raising the Connection Closed Event, this is the way you signal the container that you are giving the connection back to the pool.
Second flow: connection request when there are matching connections inside the pool.

Sequence Diagram - Matching Connections

Sequence Diagram - Matching Connections

This flow is executed whenever the container guesses there are potential matching connections. The matchManagedConnection method is invoked with the minimal connection set that the container can identify. The connection set is a key point: specification states that the container is responbile for determining the minimal set that has a potential match to avoid degrading performance while looking for the connection. Also I noticed that some containers don’t check the connections inside this Set before sending them for matching.

Implementation Tips

Here are some decisions that might help on the implementation of the ManagedConnection and ManagedConnectionFactory.

  • Store the ConnectionRequestInfo that was passed to the ManagedConnectionFactory on the creation of the ManagedConnection as an attribute inside the ManagedConnection this leads to the next tip
  • Use the ConnectionRequestInfo stored in the ManagedConnection as argument to an overload of the equals method of the ManagedConnection class this helps in the implementation of the matchManagedConnection method
  • Never ever forget to include your ManagedConnection object on equals(Object) method implementation. The tip above may lead you to forget this details. Dont do this under any circumstance since specification requires this and some containers freak out after some use time if this method is not implemented (connection borrow time goes all way up if not implemented)

Next post I’ll focus on how to signal the container that something went wrong with the connection and how to validate the connection before it is returned to the requestor.


Outbound JCA connectors introduction

Continuing with the posts about JCA I’ll start with the project of an Outbound JCA Connector that I’ll call FooJCA. First of all and let make this clear, I am not stating that this design is an optimal JCA Connector design, what I can say is that I tried to make as compliant as possible from my understanding of the documentation.

Lets start with a overall view of the main classes and interfaces involved in a JCA Connector implementation.

Foo Connector Class Diagram

Foo Connector Class Diagram

First class to take note, the FooResourceAdapter, that’s one of the connector classes that is able to directly communicate with the container and use some priviledged services (eg.: scheduling Work instances or creating timers). This ability is provided by the BootstrapContext that is passed as a parameter of the start method by the container.

Another key class that also has the ability of interacting with the container is the FooManagedConnectionFactory. As you may have already noticed, this class isn’t always container dependant, or at least it may not be (that’s up to the developer the choice of providing functionality of the Connector outside the container). The difference (between working inside the container or outside it) is usually detected when the class method createConnectionFactory is called with or without the ConnectionManager. Talking about the ConnectionManager this is a Container implemented class that is responsible for pooling connections and related work. This Container work relies on the matchManagedConnections method that is provided by the ManagedConnectionFactory, so, pay much attention to this method implementation.

Moving on, the FooConnectionRequestInfo is a implementation of the ConnectionRequestInfo interface and is the class responsible for passing Connector dependant details about the request between the Container and the JCA Connector. One of the requisites of this class is that it implements equals and hashCode.

The FooManagedConnectionFactory as you may guess is the class responsible for creating the FooConnectionFactory instances and FooManagedConnection instances as well. It does not matter if the FooConnectionFactoryImpl instance will be Container dependent or not, it will be FooManagedConnectionFactory’s role of creating it.

At least but not last, the FooConnectionFactoryImpl will be the class responsible for creating FooConnectionImpl instances when requested (this will be treated in a separate post since it is a little long topic).

And, for finishing this post, FooManagedConnectionImpl is the class responsible for wrapping a FooConnectionImpl and returning delegates (FooConnectionHandle class) that implement FooConnection interface and notifies the container about the status of the ManagedConnection connection.

That’s enough for this post, keep on watching the blog for the rest of the implementation of the Outbound JCA Connector.


Blog Stats

  • 375,197 hits since aug'08

%d bloggers like this: