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.getObjectInstanceWrapFailur
e :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.isTransactio
nInProgress :83
PooledInvokerThread-192.169.1.2:
org.hibernate.jdbc.JDBCContext.isTransactionInProgress :180
PooledInvokerThread-192.169.1.2:
org.hibernate.jdbc.JDBCContext.registerSynchronizationIfPoss
ib :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/namin
g/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 lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>
_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
|
