Performance and scalability: Performance of reflection in J2EE
Does anybody have any experiences of the use of reflection in J2EE and its performance hit?? We are looking at a sort of implementation of the Generic Attribute Access pattern using reflection. In some seperate tests we found an order of magnitude time hit from calling methods through reflection, however what we don't know is how this scales up to an industrial size environment. And is the performance hit really significant when compared to other J2EE activities?
- Posted by: Nick Leach
- Posted on: July 04 2001 10:04 EDT
Any experiences or thoughts would be welcomed,
- Performance of reflection in J2EE by markus liedl on July 04 2001 21:50 EDT
- Performance of reflection in J2EE by Dimitri Rakitine on July 06 2001 20:41 EDT
- Performance of reflection in J2EE by Ward Mullins on July 12 2001 16:57 EDT
this is not a good idea. the ejb-spec doesn't allow it.
but maybe you will use it outside of ejb's.
have a look for the jboss sources, they use it heavily.
and marc is really proud about performance numbers ...
maybe things will work better for you if you will use code generation. uml -> xmi -> java
reading/writing attribute values happens often!
have you done the lookup of the (for example) Method object each time or just once and written it to a satic field to reuse it.
hope i helped you,
--- you've got a great j2ee project and search still
--- the right java-guys? contact me: markus dot lado at gmx dot de
Thanks you for the links. Yes I did do the static initialisation of methods which improves the performance a lot.
I am a bit puzzled when you say that reflection is not allowed in EJBs. I checked the spec (EJB2, Draft 2, April 24 2001) and all I could find was that you were not allowed to use reflection to access information that would be otherwise disallowed by the Java security rules (section 24.1.2). So surely using reflection to call public methods is OK, since this does not breach any security restrictions??
no it is not. You are disregarding the restrictions placed by the acess-control (Authorization) in this scenario. I'm not sure however if reflection is a good idea, but then I'm not aware of the scenario you want to use it for. In most cases I've gotten away with using interface-adapter pattern, the performance is certainly better.
I think there is a slight misnomer here. Nick asked about using reflection in J2EE, and a common mistake is for people to assume that J2EE is the same thing as saying EJB.
According to Sun, the technologies included in J2EE are:
EJB, JSP, Java Servlet, J2EE Connector, JNDI, IDL, JDBC, JMS, JTA, JTS, JavaMail, and RMI-IIOP.
Here is the url to a page listing and briefly describing each technology in the J2EE package.
It has been my experience that reflection can be a very useful tool in J2EE development. I haven't ever used it in EJB's but I regularly use it in Servlets, especially when I'm using an MVC pattern, but I've also used it in other constructs without any performance degradation.
introspection is pretty expensive, but invocations are not, so it is a good idea to cache instrospection results.
Actually the CocoBase O/R product uses reflection out of
the box, and beans generated using CocoBase actually
outperform hand coded JDBC beans that don't use reflection.
Reflection is actually a trivial overhead in the context of
database access (around 1% actually). It's much more
expensive doing a SQL statement and all of the database
stuff than it is actually doing any reflection.
And it does scale up quite nicely. We've had customers
build EJB deployments with millions of accesses per day,
so we know it's quite scalable. In fact we've found that
it's much easier for customers to scale apps using our
generated entity beans than 'stock' beans generated by
other ide/modeling tools. A lot of it has to do with
other optimizations and design patterns that give us an
architectural edge, but nonetheless the reflection side
of things doesn't seem to have any significant overhead.
You can also use Session beans with our product that can
handle object graphs generically, and we also generate what
we call State object that can serialize the whole contents
of an EJB bean's attributes as a single network call, work
on it locally on the client, and serialize it back in a
network call. It's extremely efficient for large beans with
lots of attributes and greatly improves the scalability of
the ejb server.
We already implemented a product that uses reflection, to generically access the attributes of remote objects.
If anybody wants to evaluate/buy this product, pl. contact
mahendrad_us at yahoo dot com