Hello,
We have observed a performance problem in our J2EE-application caused by several JNDI-lookups on the Websphere-transaction when loading data from a hibernate dao. In the info log of the websphere application server the notification “INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}” is printed several times. We don’t know exactly why this notification is logged out so many times. We have debugged this problem and discovered that these notifications are initiated by the SessionFactoryUtils .doGetSession()-method of Hibernate and results from a JNDI-lookup to the websphere transaction. We asked ourselves why the lookup has to be done several times and is not cached in some way. This lookup is a performance problem because it takes long time (up to 40 seconds). Can anybody explain this observation?

Our environment:
Hibernate 3.2.1
Spring 2.0.2
Websphere Application Server 6.0.2.13

Our hibernate configuration file looks like this:

<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">
org.hibernate.dialect.Oracle9Dialect
</prop>
<prop key="hibernate.connection.datasource">
java:comp/env/jdbc/APMDatasource
</prop>

<prop key="hibernate.transaction.auto_close_session">true</prop>
<prop key="hibernate.transaction.flush_before_completion">
false
</prop>
<prop key="hibernate.transaction.factory_class">
org.hibernate.transaction.CMTTransactionFactory
</prop>
<prop
key="hibernate.transaction.manager_lookup_class">
org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
</prop>
<prop key="hibernate.cache.use_query_cache">false</prop>
<prop key="hibernate.cache.use_second_level_cache">
false
</prop>
<prop key="hibernate.show_sql">false</prop>
</props>
</property>




[23.01.07 14:40:19:953 UTC] 0000000a CacheServiceI I DYNA1001I: Die Instanz von WebSphere Dynamic Cache mit dem Namen service/cache/APMResourceCache wurde ordnungsgemäß initialisiert.
2007-01-23 14:40:20,453 [Thread-1] INFO de.fraport.biaf.apm.server.ejb.BootstrapBean.start() - started with versionversion 1.1
2007-01-23 14:40:20,516 [Thread-1] INFO de.fraport.biaf.apm.server.components.impl.DataExtractionComp.extractInitialData() - started
2007-01-23 14:40:20,578 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:20,578 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:20,594 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:20,594 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:21,032 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:21,078 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:21,078 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:40:21,078 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}
2007-01-23 14:41:03,503 [Thread-1] INFO org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}

Hello,

we are seing the exact same problems (SERIOUSLY bad performance) with "hibernate-JPA".

Alone creating an EntityManager from EntityManagerFactory results in 4 lookups.

What happens is that the WebSphereExtendedJTATransactionLookup looks up the "extendedJTATransaction" support named "java:comp/websphere/ExtendedJTATransaction" from a new InitialContext each time a Transaction (TransactionAdapter) is needed.

The way the Hibernate EntityManger (actually the Session) is implemented, this is done 4 times in a row in different places...

The 4 stack-trace from the EntityManager ctor and up is below for documenation:



Now, I've looked at the similar implementation in OpenJPA (0.9.6) that according to a post at IBM DeveloperWorks is "done right".

In OpenJPA, the extended transaction support instance is basically only look'ed up once and then stored in a static (look at OpenJPA's AutomaticManagedRuntime and WASManagedRuntime for reference).

So, I've hacked the Hibernate (3-2-3) implementation of WebSphereExtendedJTATransactionLookup to bascially do the same...

The following lines (at about line 108) are changed in my "hacked" version of WebSphereExtendedJTATransactionLookup.



Basically the extendedJTATransaction is taken out as instance variable in the inner class TransactionAdapter and put as static in WebSphereExtendedJTATransactionLookup.

Now, it is only look'ed up once.

Kind Regards

Jesper Udby
Freelance I/T consultant
Denmark :-)

Update: After nice conversation with Max Rydahl, we agreed that the extended transaction support instance did not have to be a static, but would do fine as a normal attribute of WebSphereExtendedJTATransactionLookup.

A patch has been reported in JIRA: http://opensource.atlassian.com/project ... e/HHH-2580

Jesper Udby

experienced the same problem of poor performance. patch did the trick with performance increasing 3 fold. thanks.

Hello,

unfortunately the "patch" has bascially been rejected by the Hibernate code gurus as being "not correct":



so, it is not going to make it into release 3.2.4 as expected :-(

Rgds

Jesper Udby

Just in order to avoid some possible confusion:

Mr. Ebersole seems to have changed his mind and did some minor modifications to WebSphereExtendedJTATransactionLookup before closing the 3.2.4 build. (see http://fisheye.jboss.org/browse/Hiberna ... va?r=11498)


He also put my name in as if I'm the author.

I'm not - I made the extendedJTATransaction object an instance of the WebSphereExtendedJTATransactionLookup class. According to a conversation with Max Rydahl this would ensure only one instance per EntityManagerFactory, which makes perfectly sense.

Mr. Ebersoles change makes it an instance of the TransactionManagerAdapter inner class. I don't know the inner workings of Hibernate core enough to be able to decide if they are the same. But the implementations definately differ.

I have not and are not going to test Mr. Ebersoles change.

So, if you need the performance version (and not the "correct" one according to Mr. Ebersole), take the attachment from HHH-2580.

I've got an e-mail from the IBM WebSphere Transactions Architect confirming my implementation is the "most performant".



Rgds

Jesper Udby

[/quote]

Just thought I would share my experience.

I had to performance tune an application which had a problem with the WebSphereExtendedJTATransactionLookup in terms of performance. Enormous problems.

By investigating, it turned out that the problems could be fixed by simply wrapping the services into a single transaction. Since this was read-only (reports), developer didn't surround the service with a single transaction which created a lot of calls to WebSphereExtendedJTATransactionLookup.

I had almost the same performance improvements by either replacing WebSphereExtendedJTATransactionLookup with WebSphereTransactionManagerLookup or simply wrap the service with a transaction.

Combining the two optimizations, didn't show further improvements.

Maybe some of you have problems for the same reason.

Hi,

Issue - Performance of the webapp has degraded after using the following configuration. Trying to achieve Session-per-request
<prop key="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</prop>
<prop key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WebSphereExtendedJTATransactionLookup</prop>

Some info on technologies that we are using for the webapp
WAS 6.0
Hibernate - 3.3.1
Spring - tried with the following two versions of spring - 1.2-rc2 and 2.5.6 - same behavior in terms of performance.

When we do not use the above configuration in the spring applicationcontext.xml file, performance is better which is counter intuitive because it would session/operation as opposed to session/request.

Please help...