I would like to refactor some of the JBossManagedConnectionPool stuff. While I have the patient open in implmenting this task, would it make sense to break the pool, connectionfactory, etc, etc into their own packages.
At the very least, I want to pull out the BasePool-SubClasses out of the MBean as static classes and give them their own source file.
If anything, I find this easier to read.
Work on the prototype instead.
1) There is little point refactoring something that already works and breaking everybody
while you do it.
2) We need this old implementation for "backwards compatibility" reasons
i.e. people that have stuff working, but only by luck. They are using something
undocumented or unintentional.
3) Although we stopped supporting the direct JMX deployment in 3.2.x
that will likely be some people still using it.
I had forgotten about 3.2 deployments.
In working on this 'stat's stuff, should I integrate the work I have done thus far into the current JCA implementation and then retro-fit into the jboss-jca stuff, or should I primarily focus on the prototype.
I think it would be beneficial to have some form of statistics for work management in a new 4.0.x release, but I am not married to this idea.
I implemented both the SubPoolStats as well as a working model for the stats management on WorkManagement (more on this is seperate thread).
You can apply it to both. Just don't break compatibilty, e.g. if somebody else
implements the MangedConnectionPool interface.
I don't see how I can't implement this an not break some existing compatiblity without loosening up the scoping on the ManagedConnectionPool itself. In the present implementation the JBossManagedConnectionPool MBean exposes the listStatistics() method which in turn just delegates to the ManagedConnectionPool to list sub pool statistics. The JBossManagedConnectionPool holds a reference to the MCP via the interface. To allow for exposing these statistics, either a method has to be put on the interface, or I am going to have to cast to the BasePool. The latter would seem to me to be the more obtrusive and hackish approach.
class BasePool implements ManagedConnectionPool, SomeNewStatisticsInterfaceExtension
Don't change the MCP interface.
Then in JBossManagedConnectionPool
if (pool instanceof SomeNewStatisticsInterfaceExtension) pool.extension(); else // noop
Also, I want to add a few new statistics:
a) Average use time
b) Error count
But again, the solution:
if (pool instanceof SomeNewStatisticsInterfaceExtension)
Will required a cast to support being that the JBossManagedConnectionPool only references ManagedConnectionPool. Again, it's just a variant of the other approach.
But yes, this would be a decent approach to not break the ManagedConnectionPool interface.
Also, I would like to backport this to 4.0.4...however, given time constraints we can adjust the JIRA task to reflect that it will be availabe in 5.0.
One more question:
Should we consider changing the MBean interface to reflect that the current stats being reported are cummalative versus per sub Pool?
CreatedConnectionCount - TotalCreatedConnectionCount
If we don't do something like this, I can already anticipate the questions.
There is no problem with changing JBossManagedConnectionPool to
/** The pooling strategy */ private BasePool poolingStrategy;
The issue is with the other uses of ManagedConnectionPool
that are "pluggable", e.g. the injection into the connection manager.
Please try to keep 4.0.x and 5.0.x in step.
It makes it easier to apply fixes.
But I'd say the JCA work in 4.0.4 is complete, so the changes should be only in
head until they can be applied to 4.0.5CR1
Don't change the management interface, that will break user code.
You can add new methods and deprecate the old ones.
I think I mentioned this before, but it is worth repeating.
The raw statistics should be exposed as a serializable javabean.
Any html or xml formatting is additional for things that understand
how to process it.
The important thing is to give the user the underlying raw statistics
such that they can do there own procesing without having to break
out some wacky parser.