New pool architecture

Skip to first unread message

Jesper Pedersen

Sep 14, 2015, 1:54:36 PM9/14/15
to IronJacamar Developers
I have begun to work on our new pool architecture under GitHub issue 388.

The IronJacamar 1.x pool architecture needs to be redone in order to allow each deployment to specify which pool implementation to use through the <pool type="default"> attribute. The 1.x pool contains a lot of runtime validation of the interaction - some of which can be moved to a different pool implementation such that the default setup will give a higher performance.

So, we should aim to have the following configurations available
  • Default
  • Stable
  • Leak detector

and possible more.

I'm currently working towards an overall structure as IronJacamar 1.x in order to keep the concepts similar - e.g. ConnectionManager - Pool - ManagedConnectionPool - ConnectionListener. However, some of the responsibilities will be moved around. F.ex. the pool will be responsible for creating and destroying the ConnectionListener instances, because different pool implementations may use different implementations.

Hence we need to move as much common functionality into abstract classes for maximum reuse.

Initial aim will just be the foundation for the default pool with connection listeners supporting NoTransaction scenarios.

Feel free to share ideas for improvements, and new settings.

Jesper Pedersen

Oct 1, 2015, 9:00:16 AM10/1/15
to IronJacamar Developers
I have merged an initial proof of concept that follows the ideas from the above post.

The main changes as compared to IronJacamar 1.x are:

The pool is now responsible for creating the ConnectionListener instances, and destroy them. This has the added benefit that we can move the ownership of the <max-pool-size> setting to each ConnectionListener instance, and thereby away from the usage of a ConnectionListener. This will make sure that only <max-pool-size> ConnectionListener's are activate at any given point, which is especially important in scenarios where multiple credentials are used.

The ConnectionListener now uses an AtomicInteger to represent a state machine; switching states with compareAndSet. This allows us to keep all ConnectionListener instances in a single data structure in ManagedConnectionPool, and eliminate the copying of data around. The credential at each "level" should be clearer now, as data isn't needed in method calls, but only in the constructors.

There is still a lot of work to be done on this, but the general ideas should be in code now :) The state diagram for the ConnectionListener's isn't complete for sure, and I think we will likely further divide the package structure in connectionmanager.listener to follow connectionmanager.pool - that should become more clear once we have multiple pool implementations.

However, I'll continue with looking at how we best can test the 4 component types - ConnectionManager - Pool - ManagedConnectionPool - ConnectionListener - maybe using a special annotation, or through the DeploymentRepository.

Comments, ideas, ... are most welcome !

Jesper Pedersen

Oct 13, 2015, 1:50:12 PM10/13/15
to IronJacamar Developers
The initial shutdown code has been added too - similar to IJ 1.x.

I had to add getState() and setState() to the ConnnectionListener in order to cover for shutdown cases. I think it is better than switching through changeState() using "if (!cl.changeState(FREE, DESTROYED))" and so on. Of course setState() should only be used for known end states.

But better ideas are welcome.

This means that we have a full lifecycle of the ConnectionListener's now, and as such I'll look at how we test that.

Jesper Pedersen

Jan 13, 2016, 11:22:15 AM1/13/16
to IronJacamar Developers
I have submitted which adds the initial Stable pool implementation.

The idea of the Stable pool is have additional checks that verifies that applications aren't using the pool in an improper manner, and everybody is playing a "fair" way.

The initial version makes sure that all incoming requests are done in a fair way - through a Semaphore(true) instance - and that a ConnectionListener isn't enlisted in multiple transactions at the same time - guarding f.ex. "static Connection" scenarios.

We can add additional checks in future commits, as the initial pull request was mainly focused on the overall architecture of this area.

Feedback welcome.

Stefano Maestri

Jan 14, 2016, 6:09:09 AM1/14/16
to Jesper Pedersen, IronJacamar Developers
In general I like the idea. 
I've reviewed your commit, with just one comment.
Of course we should document what check are performed by various Pool implementation.
We could also consider a pluggable Pool impl leaving users the choice of what checks enable. It's just an idea, and probably  (even if nice from a design point of view) could easily become a pain for user misunderstanding and misuse.

just my 2Cents


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
For more options, visit

Jesper Pedersen

Jan 14, 2016, 8:09:26 AM1/14/16
to IronJacamar Developers,
Yeah, documentation of the pool semantics will be important for users to choose which to run.

Having a general pool with configuration options doesn't sound like a good idea to me for the reason you mention. We should ship pool implementations that each have a clear run-time profile - if people find that there are corner cases not covered we can specific pool for that. One example is <no-tx-separate-pools> which is confusing currently, since it should only be used for Oracle DB deployments, so we will a pool that just focuses on that setting, extending the implementation from StablePool most likely. Another example would be <interleaving>.

Reply all
Reply to author
0 new messages