Rishi Shehrawat wrote:I agree that in terms of performance it is always better to have a completely stateess application, however you also need to consider overhead of persisting the cart (i am presuming that you will be using a database for it) vis-a-vis the memory saved.
Sharma Ashutosh wrote:I used Statefull session bean(Vs HttpSession) for the Shopping cart implementation for the following reasons:
1)If it is just a web application where clients for the application is always within web tier -one can use the HttpSession to store the state. But in the case of SuD, we are creating various Services(Service Facade and Service) which can be called not just from web tier based clients but also from other services,Java applications, mobile platforms etc..(keeping in mind future state extensibility).
2)This way the HTTP Session won't be bloated when the number of concurrent user count reaches to N.
3)Don't want to implement business logic in the web tier and it should be in the business tier. Moving business logic away from SFSB to the Web tier breaks encapsulation and distribution of responsibility in the application. System will be much harder to maintain and extend in future.
4)Poor reusability and integration: Implementing Shopping Cart in HTTPSession will consequence lower reusability as it will not be able to be reused directly from non-Web Application clients. Later this can't be exposed as a Service. Somewhat similar to points #1 and #4.
5)HttpSession instances do not have a mechanism that allows them to receive transaction notifications.An SFSB that implements the SessionSynchronization interface has a way to return the data of the SFSB to its original state whenever there is a transaction rollback.This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. SFSB is the only bean which can implement this interface(SLSB and MDBs can't). Data can be loaded into the bean when the transaction starts and unloaded right before the transaction finishes, while the afterCompletion callback can be used to reset default values.
Though i admit , when we use SFSB - one has to take extra steps in terms of clustered environment as they are affects various NFRs like scalability, failover and fault tolerance.
I will say whatever you are using SFSB or HttpSession-justify it in the assignment as well as in the part 3.