I'm happy to announce the release of IronJacamar 1.1.0.Beta4 - the first release of IronJacamar that targets the upcoming Java EE Connector Architecture 1.7 specification scheduled for inclusion in the Java EE 7 platform specification.
Full release notes are here.
Pool on steroids
We spent a lot time in this release going over our pool implementation, which of course controls all the physical connections to the Enterprise Information Systems such as databases.
First off we added support for capacity policies. So what is a capacity policy, and why is it important. Capacity policies are divided into two categories: incrementers and decrementers.
An incrementer capacity policy specifies the properties when a new physical connection should be added to the pool, such as
- MaxPoolSize -- increase to max-pool-size
- Size -- increase by a certain size
- Watermark -- increase until a certain size is reached
The incrementer policy will allow you to control how many or a specific size of the pool that is created when a connection isn't available for immediate check out. The default policy will remain the
Size policy with a value of 1.
A decrementer capacity policy specifies the properties when the pool is scheduled for idle timeout cleanup, such as
- MinPoolSize -- remove connections until min-pool-size is reached
- Size -- remove a certain number of connections
- TimedOut -- remove all connections that are registered with the timed out flag
- Watermark -- remove connections until a certain size is reached
The decrementer policy will allow you to optimize the resources used in a pool each time idle timeout is scheduled. The default policy will remain the
You can read more about the capacity policies here.
Next we looked at our flush strategies, which specifies which connections that are removed in case of an error on a connection. This led to
- FailingConnectionOnly (default)
- InvalidIdleConnections (new - will remove invalid idle connections)
- Gracefully (new - will remove all idle connections, and mark checked out connections for destruction upon return)
and their related strategy which works on all sub-pools across credentials. This allow much finer control of the pool in error situations.
We added some new metrics to our statistics too
to give a more detailed view of the run-time behaviour of pool.
Last we added support for specifying the initial size of the pool upon start up.
Hopefully you find all these changes just as exciting as us !
The DistributedWorkManager implementation also got an update, and both the Socket and JGroups transports are now considered ready for general testing, so give them a spin.
In order to help creating a cluster of IronJacmar instances we added some Apache Ant tasks, and Apache Maven mojos to control IronJacamar instances. Our test suite features test cases for both transports, so you can get an idea of how a cluster is created by looking there.
Java EE Connector Architecture 1.7
As stated above, this release targets the upcoming Java EE Connector Architecture 1.7 specification which will be included in the Java Enterprise Edition 7 platform specification.
The specification adds some new feature, but remains backwards compatible with the previous releases of the specification. I'll discuss these new features once the specification have received the final approval.
So hopefully soon you will see this release featured in the upcoming JBoss Application Server 8.0 release.
There were other changes in this release
- Initial support for converting a weblogic-ra.xml resource into an IronJacamar one
- Numerous component updates in order to align against our EE 7 implementation
- Bucket of bug fixes
The Road Ahead
A lot of changes (phew!) over the last 3 months to bring IronJacamar into a new league. But we are of course not stopping there - we still got more changes planned before we go into feature freeze for JCA 1.7 certification. So if you have a good idea now is the time to speak up in our forum !
For Those About to Rock, We Salute You !
[WebSite] [Download] [Documentation] [JIRA] [Forum]