New pool architecture

[Jesper Pedersen]

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]

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]

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]

I have submitted https://github.com/ironjacamar/ironjacamar/pull/445 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]

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

regards

S.

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

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