Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#46 no JMX for WrapperConnectionPoolDataSource

open
nobody
None
5
2010-12-07
2010-12-07
Jim Renkel
No

We are attempting to use c3p0 with ha-jdbc. Our application is "stand-alone": it does not live inside a j2ee container of any kind. It is "wired" with spring.

We can instantiate, configure, and wire instances of WrapperConnectionPoolDataSource and ha-jdbc and they seem to work in general.

But when we fire up a jconsole, we are not getting any beans from c3p0, as the documen tation promises in section 7.xi.

When we add a bean for com.mchange.v2.c3p0.management.ActiveManagementCoordinator, we get the C3P0Registry bean, but it reports there are no data sources.

But the data sources are there: the application generally works, and ha-jdbc is seeing and using the data sources.

Also, WrapperConnectionPoolDataSource's don't have a dataSourceName property, as implied by the section "Using C3P0Registry to get a reference to a DataSource" of the documentation. How will I be able to distinguish between the multiple connection pools if'n and when'n they get JMX mBeans?

Thank you in advance for any and all help with this.

Jim Renekl

Discussion

  • Jim Renkel
    Jim Renkel
    2010-12-08

    Some further information.

    The problem seems to be in C3P0Registry.incorporate() .

    We added readResolve as an init method for the WrapperConnectionPoolDataSource beans. When this method is invoked by spring during bean creation, C3P0Registry.incorporate() eventually gets invoked.
    It checks to see if its argument is a PooledDataSource, and if so invokes attemptRegisterRegistryMBean() to create the mBean.

    WrapperConnectionPoolDataSource's fail this test and hence don't get mBean's.

    Is there some other way to get an mBean for a WrapperConnectionPoolDataSource?

    thanks in advance for help with this.

    Jim Renkel

     
  • Bryan Varner
    Bryan Varner
    2011-05-17

    jrenkel -- I see what you're complaining about and completely sympathize with you.

    I just spent about two days making the naming schemes for JMX sane, so that I'd be able to identify and distinguish my PooledDataSource instances by ObjectNames. (It all goes back to my system monitoring needs, really)...

    My impression is that the JMX code is a bit lacking.

    Right now the ManagerMBean (DynamicPooledDataSourceManagerMBean) is very reliant on instanceof. I'm not sure how much work it would actually take to make DynamicPooledDataSource operate on more specific subclasses, but it seems to be that one of the major shortcomings of C3P0's JMX support is that it forces the notion of being a PooledDataSource (com.mchange.v2.c3p0:type=PooledDataSource) -- but ignores the fact that it may be dealing with Wrappers which implement ConnectionPoolDataSource.

    Personally, I hate the way C3P0 is doing this. I'd like to have the type= actually mean something (like the actual concrete subtype of PooledDataSource), and be able to manage any of the concrete types which get incorporate()ed.