The Ejb spec has discouraged programmers from spawning threads within session beans for a decade now.  So far, I remained a good citizen abiding by the rule – whenever needed parallelism from session beans the design would incorporate a queue backed by a message driven bean.  Thus my beans went on pleasing the JEE container.  That was but till last week.  We had a case of classic map reduce to implement within a session bean.  Altering the design was too costly a proposition so late into the product release that we decided to explore the unexplored.  Okay, okay I am over dramatizing it a bit.  I suggested and the team agreed with reluctance to introduce a thread pool managed by java.util.concurrent.ExecutorService.  The threads being spawned were nontrivial.  Each makes a remote socket connection with a image analysis server through the socket API of Jboss Remoting Server.  It queries the status of an earlier submitted image analysis request using a handle.  If the server acknowledged the status as complete it goes on to do some aggregation computations whose results are saved into the local database.  The database access is abstracted through JPA.  I hope you agree with my observation that the thread guy was a bit of a heavy weight.

At this point let me digress a bit. Is it only me who gets a repulsive reaction every time I end up at the Oracle website when looking up a Java API?  The instinctive reaction has been to shut the tab ASAP.  I hope this animosity is just a phase and Oracle’s actions in the future will make me post a public apology.  

So the next few hours I spent refactoring the code.  There were a lot of changes I did since the motive of the refactoring was to please a demanding marketing team with some blistering performance gains.  The exercise took a fairly bumpy path with transaction getting into a tangle.  Obviously the Jboss EE container I was testing on was not so easy to please when a programmer is messing around with the sacred ejb spec.  The threads spawned quickly became orphans that couldn’t get its way around.  The database updates did not refresh the entity manager appropriately.  Patience was the key at this stage.  Time spent understanding the root causes made me go over the application server codebase for a few hours to understand the way it interpreted the call stack when kindled from a session bean.  Finally after two days of writing and rewriting just about 100 lines of code I got to a point where the threads ran parallel and behaved nicely.  However I am not very sure whether this implementation will work well or will scale easily in another container.  As of now I am 100% certain that spawning threads managed using an Executor Service from within an Ejb3 session bean is possible with Jboss as the container and hibernate as the JPA provider.  However I will be extremely diligent with my integration tests when I need to port the application to another setup.  

End result: The performance hot spot vanished. The measured performance gain was 40X.




Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation