Good work, Jay. I'm surprised to find that this is an issue. Really, creation of
an InitialContext should be very lightweight (it should be optimized by the
appserver). But if it's not, then Seam should optimize it.
On Tue, Sep 30, 2008 at 2:01 PM, Jay Balunas <tech4j(a)gmail.com> wrote:
I have been looking more into the InitialContext and some of the
performance
issues surrounding it.
There are really a couple of things to look at. One is how the
InitialContext is created, and manged, and the other broad category is how
often and what items are looked up? I have investigated the first, and have
begun investigating the second.
InitialContext creation and management
------------------------------------------------
The only location were seam creates and manages the InitialContext is the
"org.jboss.seam.util.Naming" class (see:
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/N...
).
The properties are set in one location and done only once in the
initialization of seam (see:
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/I...
).
I see two issues here - one is creating the initial context every single
time it is needed, and the other is processing/checking the properties every
time it is called.
The first issue would require some caching mechanism or logic for reuse. I
am not an expert on when it makes sense to reuse an instance of the
InitialContext, and when we need to get it fresh. I can say that we
currently use they exact same properties to initialize it and those are set
during Seam initialization and do not appear to ever change once created.
Is there a way to cache and optimize this instantiation?
The second issue is that we do a certain amount of processing every time the
context is requested, this could be optimized. Currently I see a few
blocked threads on the "props.size()" call in the Naming class which is a
synchronized method on the Hashtable. This could easily be avoided.
Although we need to maintain the logic that if the property list is empty we
continue to call "new InitialContext()" and not pass in the properties
object. This is because the first thing the InitialContext constructor does
with a properties object is clone it which can be costly. I have attached a
patch that implements these changes for review.
Another item I noticed is that the only place (excluding some test code)
that does not use "Naming.getInitialContext()" is the
"org.jboss.seam.remoting.messaging.JBossConnectionProvider". It using the
"new InitialContext()" directly. Shane - is there a reason for this?
I'll write up my findings on the lookup usage asap.
Thanks,
Jay
--
blog:
http://in.relation.to/Bloggers/Jay
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org