Discussions

General J2EE: J2EE design issue

  1. J2EE design issue (3 messages)

    Hi

    I’m currently working for a company that a planning to rewrite an application to J2EE.

    Another company is working on a prototype and I’m here to help validate the design and code.

    We have to use stored procedures (for security reasons) so CMP’s can not be used. And we didn’t see any reasons then to use BMP given the extra overhead and complexity.

    We now have an application with JSP as view, a servlet as controller and a number of action classes (just plain Java klasses that calls the stored procedures).

    Whenever a JSP submits to the controller a new action class is instantiated - doing what is needs to do - and is then destroyed.

    My fear is that when you have 5.000 concurrent users the number of objects created and destroyed will be massive and leading to severe memory defragmentation and again to a lot of garbage collection which will lower performance.

    I thought about implementing the action classes as session beans and that way letting WebSphere take care of the reuse of objects instead of programming this our selves.

    I talked to a consultant on another project but he dismissed the idea og using the session beans because it was not ”best practice”.

    Does anyone has any comments for or against using the session beans?

    Best regards

    Thomas

    Threaded Messages (3)

  2. J2EE design issue[ Go to top ]

    Why did he think it was not best practice? By action class, I presume it is stateless and performs business logic - exactly what session beans are meant for, seems to me.

    Or did he mean using EJB at all is not best practice :-)
  3. J2EE design issue[ Go to top ]

    Why don't you switch to Struts? Or at least take a look to see how it realized there?

    Alex
  4. J2EE design issue[ Go to top ]

    Why don't you switch to Struts? Or at least take a look

    >> to see how it realized there?

    Very good suggestion. Struts will maintain instances of your action classes, so you will not have to worry about a large number of object creates/destroys. I would still recommend Session EJBs for your business logic (unless there are no transactional requirements).

    Jim