Tirumal Reddy Moolamalla wrote:I agree. But i have one doubt regarding usage of stateful session beans for the given use case.
As this requirement is related to shopping cart (online). We can assume certain default non functional requirements. If we dont use EJB's for this use case then we need to handle transactions and state on our own, where as the very basic purpose of EJB stateful session bean is this.
please validate my understanding.
Tirumal Reddy M
Srinivasan Rengan wrote:Jeanne, no one can deny the scalability efficiency of stateless session bean. But i was wondering if this has a bold in the blue point about session management:
Under the section ( Web-Tier State Recommendations in the above link) and further down, the recommendation has been in favour of SFSB.
Would invite your comments on the same.
Srinivasan Rengan wrote:
This is purely my perception and I am happy to hear that it is wrong too!!
Luke Murphy wrote:
1. Make JSF backing bean fat, SF SB
2. Make JSF backing bean fat, Stateless SB
3. Make JSF backing bean thin, SF SB
4. Make JSF backing bean thin, Stateless SB
No presentation or business state required.
Now, you may be saying bu8t sure you can store business state in the HttpSession, ManagedBean.
Of course you can.
But is this good separation of concerns?
Maybe in a web centric architecture you could make arguments for such but in a EJB centric architecture no way.
It would be the same as storing presentation logic / state in the stateful session bean.
There’s no place like 127.0.0.1. But I'll always remember this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton