David Jencks said:
>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
|