[hibernate-dev] Caching result (UserTransaction) of jndi lookup in o.h.t.JTATransactionFactory
Hi,
I was seeing excessive object lock contention in the JBoss jndi naming
service due to the following call sequence repeating in my application:
"PooledInvokerThread-192.169.1.2: java.util.Hashtable.get :335
PooledInvokerThread-192.169.1.2:
org.jnp.interfaces.NamingContext.useAbsoluteName :1090
PooledInvokerThread-192.169.1.2: org.jnp.interfaces.NamingContext.getObjectInstance
:1123
PooledInvokerThread-192.169.1.2:
org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure :1142
PooledInvokerThread-192.169.1.2: org.jnp.interfaces.NamingContext.lookup :705
PooledInvokerThread-192.169.1.2: org.jnp.interfaces.NamingContext.lookup :587
PooledInvokerThread-192.169.1.2: javax.naming.InitialContext.lookup :351
PooledInvokerThread-192.169.1.2:
org.hibernate.transaction.JTATransactionFactory.isTransactionInProgress :83
PooledInvokerThread-192.169.1.2: org.hibernate.jdbc.JDBCContext.isTransactionInProgress
:180
PooledInvokerThread-192.169.1.2:
org.hibernate.jdbc.JDBCContext.registerSynchronizationIfPossib :158
PooledInvokerThread-192.169.1.2:
org.hibernate.impl.SessionImpl.checkTransactionSynchStatus :1850
PooledInvokerThread-192.169.1.2: org.hibernate.impl.SessionImpl.getEntityMode :1274
PooledInvokerThread-192.169.1.2: org.hibernate.engine.StatefulPersistenceContext.addEntry
:415
PooledInvokerThread-192.169.1.2:
org.hibernate.engine.StatefulPersistenceContext.addEntity :382
PooledInvokerThread-192.169.1.2: org.hibernate.engine.TwoPhaseLoad.addUninitializedEntity
:240
PooledInvokerThread-192.169.1.2: org.hibernate.loader.Loader.loadFromResultSet :1358
PooledInvokerThread-192.169.1.2: org.hibernate.loader.Loader.instanceNotYetLoaded :1300
PooledInvokerThread-192.169.1.2: org.hibernate.loader.Loader.getRow :1197
..."
My first thought was to improve the AS class org.jnp.interfaces.NamingContext to use a
ConcurrentHashMap instead of Hashtable for the JNDI namespace. However, the Sun naming
classes are dependent on Hashtable being used. I could copy the ConcurrentHashMap to a
new Hashtable when needed but I didn't want to cause even more memory copying to occur
in the JNDI name space handling (there is already way too much cloning going on). I
started to attempt building a hybrid Hashtable class that is backed by a ConcurrentHashMap
but then I received some excellent feedback on the AS dev forum. Adrian suggested caching
the UserTransaction object in o.h.t.JTATransactionFactory, although he said that might not
work for some applications.
I tried this and it work great for me. Are there any cases where doing the "ut = (
UserTransaction ) context.lookup( utName )" at the time that method
"configure(Properties props)" is invoked, would return a different value than
later when "isTransactionInProgress()" is invoked?
I think that getting the UserTransaction early is a good performance enhancement for
JTATransactionFactory.
Any disagreement?
I'll Jira this and fix if we agree with the change.
Scott