Tag Archives: hibernate

EHCache, JMX, Hibernate and Spring

Posted by KarlP on 25 September, 2009 2 comments

We have a spring/hibernate application that we also like being able to use JConsole with, so we expose a few things via jmx.  Spring makes this pretty easy for the most part, you just use @ManagedResource on with the boiler plate config below, you’re good to go!

    <!-- Allow any bean to be exposed as an mbean.  Just use @ManagedResource and @ManagedAttribute -->
    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
        <property name="assembler" ref="assembler"/>
        <property name="namingStrategy" ref="namingStrategy"/>
        <property name="autodetect" value="true"/>
        <property name="registrationBehaviorName" value="REGISTRATION_IGNORE_EXISTING"/>
    </bean>
    <bean id="attributeSource" class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>
    <bean id="namingStrategy" class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
        <property name="attributeSource" ref="attributeSource"/>
    </bean>
    <bean id="assembler" class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
        <property name="attributeSource" ref="attributeSource"/>
    </bean>

But what about exposing beans from libraries?  For hibernate it’s easy, you just make spring create the hibernate provided bean…

    <bean id="hibernateStatistics" class="org.hibernate.jmx.StatisticsService">
        <property name="statisticsEnabled" value="true"/>
        <property name="sessionFactory" ref="nipSessionFactory"/>
    </bean>

and then modify your mbean exporter config to specifically include hibernate stats…

    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
        <property name="assembler" ref="assembler"/>
        <property name="namingStrategy" ref="namingStrategy"/>
        <property name="autodetect" value="true"/>
        <property name="registrationBehaviorName" value="REGISTRATION_IGNORE_EXISTING"/>
        <property name="beans">
            <map>
                <entry key="Hibernate:name=statistics" value-ref="hibernateStatistics"/>
            </map>
        </property>
    </bean>

Presto, hibernate stats are now available in Jconsole, wherever you specify with the key. Well and good. But what about EHCache? According to http://ehcache.org/documentation/jmx.html there’s mbeans provided here too, so we can just list them in our bean config and add them to the list with hibernate right? MAYBE! You can get the cache manager working like this…

    <bean id="cacheManager" class="net.sf.ehcache.management.CacheManager">
        <constructor-arg ref="innerCacheManager"/>
    </bean>
    <bean id="innerCacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="shared" value="true"/>
    </bean>

and then refer to cacheManager in the list of beans to export. But when it comes to the CacheStatistics object, you need to somehow get at the EhCache object itself, and spring bean config doesn’t have any way of getting at that easily.

Instead, you can just ask EhCache to register itself with the mbean server. This is covered at http://forum.springsource.org/showthread.php?t=63453 but I just wanted to cover it with a bit more information…

The extra beans you need for full EhCache jmx management, on top of the hibernate stats config above is:

    <!-- only needed explicitly because ehcache needs it to register itself -->
    <bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
      <property name="locateExistingServerIfPossible" value="true"/>
    </bean>
 
    <!-- ehcache needs to register itself, we can't just give the bean to jmx ourselves -->
    <bean id="ehCacheMBeanRegistration" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property name="staticMethod" value="net.sf.ehcache.management.ManagementService.registerMBeans"/>
        <property name="arguments">
            <list>
                <ref bean="innerCacheManager"/>
                <ref bean="mbeanServer"/>
                <value>true</value>
                <value>true</value>
                <value>true</value>
                <value>true</value>
            </list>
        </property>
    </bean>
    <bean id="innerCacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="shared" value="true"/>
    </bean>

Adabas D, hibernate and compound primary keys

Posted by KarlP on 11 November, 2008 None comments

lastly, My (least) favourite application here at work, that beauty that uses Adabas D as the database server, also makes liberal use of compound keys. However, in our useage, one portion of that key is always fixed, so when I started trying to replace a lot of the raw jdbc with hibernate as I mentioned earlier, I just put the fixed portion as a regular column, and labelled the varying column with the @Id notation. This worked just fine for reads, and for most of the basic writes we were doing at the time. (Where the write simply changed a field in the table) However, when we tried to update an object property, (By object I mean, myObject.complicatedChild = blah, not just myObject.integerField = wop) it all failed.

Error: ASSIGNMENT IMPOSSIBLE, CHAR VALUE TOO LONG
SQLState:  22001
ErrorCode: -2010

Excellent…..

SAP isn’t very helpful on what that means, it seems to just try and say that, well, you tried to put too big a char value into a char column. Like hell I said, but went off to hibernate debugging to see just what exactly was going on. Which led me to discover that the hibernate code simply wasn’t working!

The generated hibernate code:

update TABLE set
FIXED_PART_OF_KEY=3,
ID_OF_OTHER_OBJECT=4
where REGULAR_PART_OF_KEY ='somekey'

This by itself was failing! but if you take out the FIXED_PART_OF_KEY from the update though, it all works just fine! (This was actually a longer process of elimination, with a lot more rows initially) So, even though there is only one row where the regular part of the key matched “somekey” I went ahead and converted to fully using compound keys across the project, suspecting some inanity from within.

And low and behold, it all started working again. Hooray!  I use the @IdClass method, as it seems to fit our code best.

So:

  1. add @IdClass to original entity
  2. remove @Column attributes from the original ID entity, and put them in the new IdClass
  3. put @Id attributes on both columns in the original entity
  4. add equals and hashcode implementations to the IdClass, and mark as @Embeddable
  5. Add a constructor to the IdClass to deal with the “fixed” portion of the key

Lastly, any other object that was referencing this just by the regular part of the key now needs to be updated as well. so @JoinColumn get’s replaced with @JoinColumns, and the dangling property for the unused fixed portion of the key is deleted.

Moral of the story? Don’t use Adabas D, it’s archaic and has a terribly old jdbc driver. Don’t use Compound Keys if you have a choice. It just causes extra pain.

Versions used: hibernate 3.2.6GA and java 6. JDBC driver for adabas provided by SAG.