Hi all, I am refactoring an EJB application in which the original designer made everything an EJB. Also, for those situations where some check needed to be made against the database, the JDBC/SQL code is embedded in the EJB bean class itself (which I don't like). In some small experiments, I took one of the Stateless SB classes and made it into a simple DAO which performed the same query. I wrote a little test script, and it ran anywhere from 10 to 30 percent faster when calling the DAO rather than going through the SB. The point of my task is to (1) improve the performance of the application and (2) make the code more easily maintainable. I wanted to ask you Ranchers about the implications of replacing Stateless SB's whith DAO's, where we are currently only doing simple queries before performing an insert. Advantages I see:
Better performance (in my observations) without the associated container overhead.
Code can be used outside of a J2EE environment (like standalong apps).
Code is easier to maintain (maybe just my opinion here)
No declarative transaction demarcation for those methods (don't use anyway)
No declarative security for those methods (don't use anyway).
No remote access to those methods (don't need it).
Are there any other implications with regard to transactions I'm not thinking of? Thanks for any input.
Joined: Feb 22, 2002
SSB gives you instance pooling for better scalability? IMO you're not really giving us enough detail to understand your issue. It sounds like your application is just running a query and that it's not part of a longer sequence of actions that need to be atomic. In a sense the session bean acts as a facade for your client. They say this makes changes to the back end easier to implement.