ConnectionManagers
33 views
Skip to first unread message
Jesper Pedersen
Dec 2, 2015, 10:33:04 AM12/2/15
to IronJacamar Developers
Hi,
I have merged the first part of our new ConnectionManager's in commit https://github.com/ironjacamar/ironjacamar/commit/577032c731124a17580525a0d7e916a9d46e4488
The implementation tries to share as much code as possible in abstract classes, as seen in AbstractTransactionalConnectionManager and AbstractTransactionalConnectionListener. These classes also assume that the applications using the resource adapter doesn't have any major issues, like "private static Connection", and therefore a lot of checks have been removed compared to IronJacamar 1.x. We will re-add these sort of checks in a "stable" configuration later.
AbstractTransactionalConnectionManager is responsible for enlisting the ConnectionListener in the active transaction, while AbstractTransactionalConnectionListener does the actual enlisting and keeps track of the associated Synchronization instance.
The AbstractPool class has been expanded to understand transaction based invocations, e.g. handing out an existing ConnectionListener if one exists, or assigning a new ConnectionListener upon first invocation. The ConnectionListener's are maintained in an internal map based on the transaction key, and the associated ManagedConnectionPool instance. We won't be using TransactionSynchronizationRegistry for our map implementation in IronJacamar 2, as we need to know all information ever recorded - something that TSR doesn't allow w/o a lot of book keeping - which will become important later once we revisit our Reauth pool. Our map is cleaned up by a Synchronization instance (TransactionMapCleanup).
The listener implementations have been moved to a listener.dflt package to follow the pool implementation. Future implementations for other configurations can extend either the abstract base classes, or from another configuration.
The commit contains test cases that verifies the lifecycle of the ConnectionListener vs. the transaction - e.g. shows that NoTransaction doesn't have an impact, and LocalTransaction / XATransaction are bound to the transaction boundary.
There is still a lot of work left, I'll continue to look at our new CachedConnectionManager component, and we need to propagate the remaining deployment configuration to the ConnectionManagerConfiguration and PoolConfiguration classes. Then this functionality needs to be enabled, like WrapXAResource and so on.
Comments, feedback, questions about this commit most welcome.
Best regards,
Jesper
I have merged the first part of our new ConnectionManager's in commit https://github.com/ironjacamar/ironjacamar/commit/577032c731124a17580525a0d7e916a9d46e4488
The implementation tries to share as much code as possible in abstract classes, as seen in AbstractTransactionalConnectionManager and AbstractTransactionalConnectionListener. These classes also assume that the applications using the resource adapter doesn't have any major issues, like "private static Connection", and therefore a lot of checks have been removed compared to IronJacamar 1.x. We will re-add these sort of checks in a "stable" configuration later.
AbstractTransactionalConnectionManager is responsible for enlisting the ConnectionListener in the active transaction, while AbstractTransactionalConnectionListener does the actual enlisting and keeps track of the associated Synchronization instance.
The AbstractPool class has been expanded to understand transaction based invocations, e.g. handing out an existing ConnectionListener if one exists, or assigning a new ConnectionListener upon first invocation. The ConnectionListener's are maintained in an internal map based on the transaction key, and the associated ManagedConnectionPool instance. We won't be using TransactionSynchronizationRegistry for our map implementation in IronJacamar 2, as we need to know all information ever recorded - something that TSR doesn't allow w/o a lot of book keeping - which will become important later once we revisit our Reauth pool. Our map is cleaned up by a Synchronization instance (TransactionMapCleanup).
The listener implementations have been moved to a listener.dflt package to follow the pool implementation. Future implementations for other configurations can extend either the abstract base classes, or from another configuration.
The commit contains test cases that verifies the lifecycle of the ConnectionListener vs. the transaction - e.g. shows that NoTransaction doesn't have an impact, and LocalTransaction / XATransaction are bound to the transaction boundary.
There is still a lot of work left, I'll continue to look at our new CachedConnectionManager component, and we need to propagate the remaining deployment configuration to the ConnectionManagerConfiguration and PoolConfiguration classes. Then this functionality needs to be enabled, like WrapXAResource and so on.
Comments, feedback, questions about this commit most welcome.
Best regards,
Jesper
Stefano Maestri
Dec 14, 2015, 7:52:49 AM12/14/15
to IronJacamar Developers
Hi,
I had a look and it's good.
Looking forward for other implementation steps and to integrate it w/ my current work on unified security.
BTW I've merged locally your changes w/ what I'm doing and there isn't serious conflict.
regards
S.
Jesper Pedersen
Jan 21, 2016, 11:29:13 AM1/21/16
to IronJacamar Developers
I have merged the initial version of the ConnectionManagerConfiguration class, that holds the rest of the configuration parameters we need from the activation.
As a PoC I did use isConnectable() and isWrapXAResource(), so the basic structure should be ok.
The questions if the various options belongs in ConnectionManagerConfiguration, PoolConfiguration or the deployment repository. However, I don't see this as a big issue for now, as the options can be moved around as part of the work enabling them in the container.
Likely a rule could be that the option appears at the "lowest" level where it is used - e.g. if only used in pool, then it goes into PoolConfiguration.
Thoughts ?
As a PoC I did use isConnectable() and isWrapXAResource(), so the basic structure should be ok.
The questions if the various options belongs in ConnectionManagerConfiguration, PoolConfiguration or the deployment repository. However, I don't see this as a big issue for now, as the options can be moved around as part of the work enabling them in the container.
Likely a rule could be that the option appears at the "lowest" level where it is used - e.g. if only used in pool, then it goes into PoolConfiguration.
Thoughts ?
Tom Jenkinson
Jan 22, 2016, 5:09:46 AM1/22/16
to Jesper Pedersen, IronJacamar Developers
Sounds like a good option. If an option is ever removed it will then affect the minimum number of files.
Thoughts ?--
You received this message because you are subscribed to the Google Groups "IronJacamar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ironjacamar-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jesper Pedersen
Jan 28, 2016, 8:55:01 AM1/28/16
to IronJacamar Developers
I have merged connection validation, with a fast fail escape (isUseFastFail()) in commit https://github.com/ironjacamar/ironjacamar/commit/cdf10ebae147e987b9803f641edd910e4aad1fd7
The functionality is similar to IronJacamar 1.x, but the ManagedConnectionPools are now inserted into a TreeMap, with a Comparator which sorts the ManagedConnectionPools after when they last received a validation invocation. This way only MCPs that has an "interval / 2" timestamp to be invoked. Each ConnectionListener still contains a timestamp of when it was last validated, so no changes there.
The question is how we should do testing of all these "minor" features. I don't see us writing a dedicated resource adapter for each of these use-cases, as it would just clutter the test suite.
A suggestion would be a more general resource adapter which has config-property's that enables the testing scenario needed - think "FailOnFirstValidation". Of course we don't want to go overboard with options either, so there must be a balance.
Two other things popped up during this development.
1. Our thread handling for our services are different at the moment. I think a common way to do it would be of benefit.
2. Maybe we could benefit from an AbstractManagedConnectionPool which contains helper methods, f.ex. a method like validateConnectionListener
Comments ?
The functionality is similar to IronJacamar 1.x, but the ManagedConnectionPools are now inserted into a TreeMap, with a Comparator which sorts the ManagedConnectionPools after when they last received a validation invocation. This way only MCPs that has an "interval / 2" timestamp to be invoked. Each ConnectionListener still contains a timestamp of when it was last validated, so no changes there.
The question is how we should do testing of all these "minor" features. I don't see us writing a dedicated resource adapter for each of these use-cases, as it would just clutter the test suite.
A suggestion would be a more general resource adapter which has config-property's that enables the testing scenario needed - think "FailOnFirstValidation". Of course we don't want to go overboard with options either, so there must be a balance.
Two other things popped up during this development.
1. Our thread handling for our services are different at the moment. I think a common way to do it would be of benefit.
2. Maybe we could benefit from an AbstractManagedConnectionPool which contains helper methods, f.ex. a method like validateConnectionListener
Comments ?
Jesper Pedersen
Mar 15, 2016, 11:14:29 AM3/15/16
to IronJacamar Developers
I have merged lazy connection manager support in commit https://github.com/ironjacamar/ironjacamar/commit/e8a424909e9e6ea14bdc6e61eaf138aa888c2c61.
The LazyEnlistableConnectionManager part is pretty straight forward, as we don't enlist the connection listener instance if 'enlistment' is true, and the ManagedConnection is a LazyEnlistableManagedConnection.
For LazyAssociatableConnectionManager we carried over our API from the 1.2 series - https://github.com/ironjacamar/ironjacamar/blob/master/core/src/main/java/org/ironjacamar/core/api/connectionmanager/ConnectionManager.java - to allow resource adapters to have finer control over the association lifecycle. The container will try and allocate a new ConnectionListener if one isn't already associated with the active transaction. If that fails it will try and kill a free connection listener. If that also fails for NoTransaction deployments it will find a connection listener with the same credentials and assign that. We don't move connection listener instances between transactions, and hence threads, since we assume that they will be enlisted at some point during its lifecycle. This would really require the resource adapter to use IronJacamar's API (dissociateManagedConnection), so this use-case isn't very likely in most resource adapter implementations. Therefore this corner-case is left out (for now).
A number of test cases has been added to test both the standard cases, as well as the CachedConnectionManager cases.
Feedback, comments, ... is most welcome.
The LazyEnlistableConnectionManager part is pretty straight forward, as we don't enlist the connection listener instance if 'enlistment' is true, and the ManagedConnection is a LazyEnlistableManagedConnection.
For LazyAssociatableConnectionManager we carried over our API from the 1.2 series - https://github.com/ironjacamar/ironjacamar/blob/master/core/src/main/java/org/ironjacamar/core/api/connectionmanager/ConnectionManager.java - to allow resource adapters to have finer control over the association lifecycle. The container will try and allocate a new ConnectionListener if one isn't already associated with the active transaction. If that fails it will try and kill a free connection listener. If that also fails for NoTransaction deployments it will find a connection listener with the same credentials and assign that. We don't move connection listener instances between transactions, and hence threads, since we assume that they will be enlisted at some point during its lifecycle. This would really require the resource adapter to use IronJacamar's API (dissociateManagedConnection), so this use-case isn't very likely in most resource adapter implementations. Therefore this corner-case is left out (for now).
A number of test cases has been added to test both the standard cases, as well as the CachedConnectionManager cases.
Feedback, comments, ... is most welcome.
Stefano Maestri
Mar 15, 2016, 11:56:59 AM3/15/16
to IronJacamar Developers
In general LGTM.
I agree also to focus only on proved useful use-cases, keeping other use-cases only when we run into them. Would be good to document those choices somewhere, with also all what we already known it's not implemented and what could be the strategy to extend current implementation. Just for future record and moreover to give some input to community's contribution in this area.
regards
S.
Stefano Maestri
Mar 15, 2016, 11:58:24 AM3/15/16
to IronJacamar Developers
Maybe opening issues for community w/ use cases left out would be good.
regards
S.
Reply all
Reply to author
Forward
0 new messages