SourceForge Submitter: genman .

I've been profiling JMS code. When a JMS message is
added to the server, the persistence manager locates an
appropriate DataSource.

Out of the time spent in
org.jboss.mq.Connection.sendToServer, about 28% of the
time is getting the database connection through
jdbc.WrapperDataSource.getConnection to do its work.
This is after the pool has been initialized, etc. (40%
is actual persistence, though most of it is the message
serialization.)

I suspect a lot of the work is calculating a hashCode
on the javax.security.auth.Subject. SubjectCriKey and
SubjectKey should have this value cached. Ideally,
when one is accessing the local DB, none of this auth
stuff should have to take place. Looking at the source
for Subject.java, the hash code is not kept.

BaseConnectionManager2.allocateConnection %CPU=27.949
%Time=27.963 calls=411

Allocations I've seen:

JBossManagedConnectionPool$SubjectActions
is created 3284 times (for 411 getConnection calls)
java.util.Properties (1642 times)

(Disclaimer: This was done through JBoss profiler,
which may or may not create real numbers. It does
look, though, that CX is pretty slow for some operations.)