<connectionmanager>
<realm-bridge>TargetRealm</realm-bridge>
<blockingTimeout>100</blockingTimeout>
<maxSize>10</maxSize>
<useTransactions>true</useTransactions>
<useLocalTransactions>true</useLocalTransactions>
<useTransactionCaching>true</useTransactionCaching>
<useConnectionRequestInfo>false</useConnectionRequestInfo>
<useSubject>true</useSubject>
</connectionmanager>
There are basically 2 kinds of problems with this:
1. There are dependencies among the flags in that some of the flags have meaning only if others have a certain value. For instance useTransactionCaching is looked at only it useTransactions is set.
2. Although the underlying interceptor-based design of the ConnectionManager is very flexible and should let you easily set up your own custom style ConnectionManager, right now you are limited to the particular implementation supplied in geronimo. Using a different ConnectionManager implementation would involve writing a new deployment framework.
One possibility to improve (1) would be to use more nested xml with the schema grammar controlling what combinations are possible
for instance:
<connectionmanager>
<localTransactions/><!-- implies useTransactions and useTransactionCaching-->
<containerManagedSecurity>
<realmBridge>targetRealm</realmBridge>
</containerManagedSecurity>
<pooling>
<blockingTimeout>100</blockingTimeout>
<maxSize>10</maxSize>
<partitionByConnectionRequestInfo/>
<partitionBySubject/>
</pooling>
</connectionmanager>
One possibility to improve (2) would be to allow either the explicit configuration such as that just shown or a reference to a gbean. The deployer would assume that the gbean implemented the appropriate interfaces, and normal gbean configuration could be used with it. With an abstract superclass that had the methods to call an interceptor chain, a user could easily write a connection manager implementation with any custom hardcoded list of interceptors.
<connectionmanager- ref>myapp:role=ConnectionManager,name=MyConnectionManager</ connectionmanager-ref>
I'd appreciate comments and suggestions about other ways to provide clearer configuration options and more flexibility.
Many thanks, David Jencks
