[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...

[Scott Marlow]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>