hi guys,
I know this seems to be a vague question, I really want to find out the scenarios where session bean is really required ?
I have an e-commerce application wherein we are required to provide interfaces for customers, retailers, and manufactures to transact. This involves searching for products that match a particular criteria, adding new products, updating catalogs, deleting products, shopping , etc.
I'll explain in brief about our architechture.
We have used JSPs for the View which take in the search criteria.
Servlets as the controller which takes in the request parameters, constructs a serializable object (Value Object) from these parameters and passes it to the stateless session bean. THe session bean get a database connection and fires the SQL on it, gets the result and gives it back to the servlet. THe servlet then forwards to the
JSP file which provides the presentation logic to display the search results.
Now the question here is, do I really need a session bean here.
I do not use any container services such as transactions, security, etc.
So i decided to write a simple
java class and do the same thing that my session bean does.
If instance pooling is a consideration, I can increase the size of the servlet pool in weblogic.
What are the trade offs in both my approaches ?
1. Using stateless session beans.
2. Using simple java classes in place of session beans.
This alternate approach was used for searches, which have a simple SELECT statement.
I decided to get rid of session beans for my update and inserts (creation) as well.
Is it a feasible solution in my kind of application that allows dirty reads, that does not have a heavy hit count.
Deepak