Based on my experience with the JBoss ConnectionManager implementations, I'm convinced that due to the flexibility desired any monolithic or inheritance based approach will quickly become unmaintainable.Even if I do not have your experience, this is one of the conclusion I reached after having digested the specifications. And I tried to avoid a strict inheritance by partitioning the connection pool. Basically, each partition has a specific function: the factory partition creates the ManagedConnections, the idle partition adds a ManagedConnection to an active; local or XA transacted partition. XA partition enlists the ManagedConnection and returns to allocated Connection to the caller.
I've started writing an interceptor based ConnectionManager and hope it will be in a previewable state soon. The idea is that each chunk of functionality, such as getting a mc from a mcf, or enlisting a mc in a transaction, is in a separate interceptor. By combining interceptors you get a fully functional ConnectionManager.This is a great idea. Actually, I wanted to insert up-front the connection pool of ManagedConnection an interceptor stack in charge of populating what I have called a ManagedConnectionState. This instance is passed to the pool and the pool has the responsibility to do the right thing based in the state of the ManagedConnection to be allocated.
The TransactionManager is required to keep track of this thread association for us, so we don't need our own ThreadLocal. I'm less familiar with the specs for security but I think any reasonable Security Manager should also keep track of thread to security domain/subject associations.I agree. I had a look to the TransactionManager implementation, which has been checked in just a few days ago and it will be easy to get an handle on the current transaction context.
I think the only circumstance in which a ConnectionManager is serialized is when a connection handle is serialized, perhaps when an ejb instance is passivated. The solution I came up with in JBoss is to have a serializable proxy that is just a handle. The first time it is used it looks up the actual connection manager implementation (via jmx): after that it can used the (transient) reference.I have fixed the proposed implementation. Basicaly the ConnectionManager is a light object which looks up for our actual ConnectionManager - I called it MasterPartition - which is a singleton.
This is one of my big complaints about the connector spec. What I did was to partition the pool based on configurable criteria (just one pool, by Subject, by ConnectionRequestInfo, or by Subject and ConnectionRequestInfo) and supply exactly one match choice to matchManagedConnection. I think this is a reasonable default strategy: in nearly 2 years in JBoss, only one person had a connector for which this was not appropriate. However, we should also have the "dumb" strategy you have implemented. I've wondered if there is some middle ground, but haven't thought of it yet.I agree. It was on my plan to add partitions related to ConnectionRequestInfo and Subject however in a first stage I have implemented a simple thing.
Regarding the matchManagedConnection strategy, I had a thought about it and a possible mechanism is to define some latchs which are distributed amongst the available set of ManagedConnections. This is a mechanism used by Oracle in order to avoid contention on various structures and it definitively works for them.
I'm afraid I haven't actually had a chance to look at your code yet. I'm trying to implement some of the parts that appear to be missing from your code in my interceptor framework (transaction stuff, mostly) and I hope we can work together to get everything in.That's ok, it was an ugly preview. I will post a final proposal during the week (I need some time to write a deployer for the outbound-resourceadapter node).
Thanks for your comments. Gianny
_________________________________________________________________ Trouvez l'�me soeur sur MSN Rencontres http://g.msn.fr/FR1000/9551
