CachedConnectionManager

[Jesper Pedersen]

Hi,

I have merged the initial version of our new CachedConnectionManager component (https://github.com/ironjacamar/ironjacamar/commit/0fdc751f212d02232dde8dc8a468e6b23ef47ff2).

The CachedConnectionManager pretty much follows what we had in the 1.x branches, with a cleanup interface as we don't need any separation in that area.

The new implementation is capable of merging connection handles from multiple ConnectionListener instances upon transaction start, which reduces the physical connections used and thereby freeing up the pool. The whole CachedConnectionManager thing is still a broken concept, because applications keep obtaining connections before a transaction is started, and still expects them to be enlisted.

For now I have kept the listConnections() functionality, but we should seriously consider moving this functionality to the janitor component attached to the pool, once we get to that point.

The commit also contains some test cases which verifies the deferred enlistment scenarios, and auto close of connections - another thing applications can't figure out...

Feedback, questions, comments... most welcome !

[Tom Jenkinson]

I am providing my feedback on here as requested. I wondered about the commit and how it is swallowing certain exceptions plus there appears to be no tracing. Is that intentional?

Also, it would aid following the code if the motivation which you have provided in this discussion were reflected on the issue (or a link to the design discussion added to the issue if that is your preference).

--
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]

On Wednesday, December 16, 2015 at 5:09:32 AM UTC-5, Tom Jenkinson wrote:

I am providing my feedback on here as requested. I wondered about the commit and how it is swallowing certain exceptions plus there appears to be no tracing. Is that intentional?

For now, yes - as we need to setup proper logging for the entire environment. But all log statements will be activated as part of that work.

Also, it would aid following the code if the motivation which you have provided in this discussion were reflected on the issue (or a link to the design discussion added to the issue if that is your preference).

Sure, the new part is https://github.com/ironjacamar/ironjacamar/blob/master/core/src/main/java/org/ironjacamar/core/connectionmanager/ccm/CachedConnectionManagerImpl.java#L174-L188 - the rest is more or less the same as 1.x.

But, yeah, each issue should be updated to include the forum design/discussion.

[Tom Jenkinson]

Thanks Jesper - I think that sounds like a good approach.