Re: [jboss-dev] Oops, javax.naming.spi.* is dependent on Hashtable, this will make it difficult to change the JBoss jndi naming service to use ConcurrentHashMap instead of Hashtable...
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.
Good point about the serialization, I'll handle that too.
This is a difficult problem (not the serialization but the change in
general). I don't want to add a lot of code that converts between
Hashtable + ConcurrentHashMap as that could hurt performance. Will have
to think about this for a bit more.
Thanks for the feedback!
Scott
Adrian wrote:
Hi Scott,
I missed your original post, probably because you posted during
Java One. ;-)
But I don't understand what you are doing?
There shouldn't be any contention on a naming context.
A naming context is not thread safe, the application has to
synchronize on it anyway if it is using it concurrently!
http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html
If you are going to change it, then you need to be aware
that this it is part of the "serialized form" and must still
serialize as a Hashtable for compatibility with earlier versions.
Regards,
Adrian
On Wed, 2007-07-11 at 10:36 -0400, Scott Marlow wrote:
> 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
>