Discussions

Performance and scalability: lookup to session-façade is bottleneck, is handle solution?

Bookmark and Share Get thread feed

  1. lookup to session-façade is bottleneck, is handle solution? (4 messages)

    • Posted by: Bart Du Bois
    • Posted on: November 24 2001 11:57 EST
    I am currently in a project in which Apache-Tomcat-JBoss-MySQL is used (in
    parallel to an approach without the JBoss - direct JDBC) to produce a web-
    based application.

    [We're not sure whether a distributed approach provides benefits for the
    future]

    While stress-testing both the pure JDBC and the JBoss-version, my attention
    was drawn to a major performance-bottleneck in the JBoss-version.

    Right now, I let my JSP's contact a JavaBean which handles the lookup with
    the session-façade. In these stress-tests, we dropped the JSP's and made our
    own clients which used the same JavaBeans as did the JSP's.

    Now, JBoss itself wasn't the problem, but the jndi-lookup to the session-
    façade was just terrible.

    We noticed that as the time between the different lookup's got smaller, the
    response-time leaped up dramatically. In our current application, each JSP-
    request leads to a new instance-creation of the JavaBean, which does its own
    lookup to the session-façade.

    I wonder whether this bottleneck would be reduced when I would only do 1
    lookup the first time, and save a handle to the session-façade for future
    use. Each next JSP-request would then let the JavaBean find the session-
    façade using that handle.

    Do you guys think this would improve performance, or is it just another way
    of looking up the session-façade which results in the same bottleneck?
    Reply to this

    Threaded Messages (4)

  2. lookup to session-façade is bottleneck, is handle solution?[ Go to top ]

    You can always cache the Context object as well as the Home stub objects. This will take care time being consumed in your case.
    Reply to this Reply to original

  3. lookup to session-façade is bottleneck, is handle solution?[ Go to top ]

    Make the facade a SFSB (Stateful Session Bean) and cache the handle to the EJBs.
    This will imrove the performance (hopefully).
    Regards
    /Henrik
    Reply to this Reply to original

  4. lookup to session-façade is bottleneck, is handle solution?[ Go to top ]

    Look at some J2EE design pattern from sun, in particular Business Delegate and Service Locator

    http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/J2EEPatternsRoadmap.html
    Reply to this Reply to original

  5. lookup to session-façade is bottleneck, is handle solution?[ Go to top ]

    Thank you all very much for your replies!

    Declaring the session-façade as a stateful session bean helped. I didn't get those irritating ConnectExceptions anymore... I'm planning on digging deeper to find the real cause though. Standard maxsize for stateless session beans in JBoss 2.4.1 wasn't the problem.

    I am planning on comparing the stateless-stateful-implementation, so I can base my conclusions on hard numbers (will try to post them here).

    I did found another interesting thing. I'm using a auto_increment field for mapping my external id's to internal id's (those bean-names end with IdMap). I had to write these with BMP, since CMP doesn't allow this (right?). So in these IdMap-beans, I retrieve a connection. With the standard max-connection-count of 10, I got nullpointer-exceptions in the findByPrimaryKey of these IdMaps. My guess is a connection wasn't available at the time so they just returned null. This makes my BMP-beans the weakest link.

    Do I just have to deal with this or can is there a way to implement these IdMaps with CMP. Those darn auto-increment-fields...
    Reply to this Reply to original