I wrote a few months ago about changing the jndi implementation to use ConcurrentHashMap instead of Hashtable. This is to fix a concurrency bottleneck in org.jnp.interfaces.NamingContext (I'm seeing 2-3 second object lock contention on instance variable " org.jnp.interfaces.NamingContext.env". Unfortunately, the interface javax.naming.Context is dependent on Hashtable and NamingContext has to implement Context. There are also many other dependencies on Hashtable in the javax.naming.spi package. I'll try to hack around the dependencies. I don't have a question but just sharing my status on this attempt. Scott _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Hi Adrian, The 2-3 second contention that I'm seeing is on the following call stack: "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 ..." I am looking at changing the Hashtable to a ConcurrentHashMap which could help some applications run more concurrently.

Adrian wrote: > On Wed, 2007-07-11 at 11:58 -0400, Scott Marlow wrote: > >> Hi Adrian, >> >> The 2-3 second contention that I'm seeing is on the following call stack: >> >> "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 >> ..." >> >> >> I am looking at changing the Hashtable to a ConcurrentHashMap which >> could help some applications run more concurrently. >> > > This just looks like a bug in Hibernate. > > It is caching the naming context in the JTATransactionFactory > and then using it concurrently across threads, without > the required synchronization. > > This probably only works by luck, because it is looking up in > "java:comp" for the UserTransaction which is a read only context > constructed at deployment time and is therefore unlikely > to have concurrency problems. > > I'm sure if this class was changed to create a new initial context > for each request you wouldn't see the contention, but that > might not be very efficient either. Depends how often the > isTransactionInProgress() is invoked. > > I don't see why it isn't caching the UserTransaction instead anyway. > It's probably because some people use Hibernate across transaction > demarcation boundaries in at least dubious, if not broken ways. Hibernate does offer a few alternatives to the JTATransactionFactory (applications can also implement their own org.hibernate.transaction.TransactionFactory solution). There is a JDBC based implementation that shouldn't have this problem. There is also a CMT solution that also shouldn't hit this problem (it caches a transactionmanager.) I'll try caching the UserTransaction in the Hibernate JTATransactionFactory.

On Wed, 2007-07-11 at 16:15 -0400, Scott Marlow wrote: > I tried caching the UserTransaction and that eliminated the contention. > > I owe you a pint the next time you visit! > Give it to Bill (Burke), it'll go towards my Guinness allowance for breaking the build. :-) > ________________

Does JTA/JTS mandate that a UserTransaction reference obtained and held indefinitely understand the context in which calls against it are invoked? And that it react accordingly?

If so, then no big deal I can change this. As background, JTATransactionFactory is scoped via a SessionFactory. So if JTATransactionFactory were to cache this reference, it would be cached for the duration of that SessionFactory (hence my question above). The only reason I did it this way was perhaps a misunderstanding of how UserTransaction worked in this scenario (based on question above). As always, my JTS knowledge pales in comparison to yours. If I misunderstood the above please let me know... > This just looks like a bug in Hibernate. > > It is caching the naming context in the JTATransactionFactory > and then using it concurrently across threads, without > the required synchronization. > > This probably only works by luck, because it is looking up in > "java:comp" for the UserTransaction which is a read only context > constructed at deployment time and is therefore unlikely > to have concurrency problems. > > I'm sure if this class was changed to create a new initial context > for each request you wouldn't see the contention, but that > might not be very efficient either. Depends how often the > isTransactionInProgress() is invoked. > > I don't see why it isn't caching the UserTransaction instead anyway. > It's probably because some people use Hibernate across transaction > demarcation boundaries in at least dubious, if not broken ways. :-) _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Does JTA/JTS mandate that a UserTransaction reference obtained and held indefinitely understand the context in which calls against it are invoked? And that it react accordingly? If so, then no big deal I can change this. As background, JTATransactionFactory is scoped via a SessionFactory. So if JTATransactionFactory were to cache this reference, it would be cached for the duration of that SessionFactory (hence my question above). The only reason I did it this way was perhaps a misunderstanding of how UserTransaction worked in this scenario (based on question above). As always, my JTS knowledge pales in comparison to yours. If I misunderstood the above please let me know...