geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <gianny_dam...@hotmail.com>
Subject Re: JCA Connection Management proposal
Date Tue, 30 Sep 2003 05:46:13 GMT
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


Mime
View raw message