I found this question in one of the Mock test. ---------------------------------------------- You are developing an online shopping store for an art gallery. The company aims to bring fine art to the masses and expects a huge volume of traffic through the site. The site allows customers to pay for goods and arrange delivery methods using credit cards. You have read through the requirements and have a rough design in your head. Which of the following is the most appropriate rough design for this site?
AHave an Entity Bean to represent the customer. Use a Servlet to manage the users session and use BMT to manage the transactions. BHave an Entity Bean to represent the customer. Use a Stateful Session Bean to manage the users session and use BMT to manage the transactions. CHave an Entity Bean to represent the customer. Use a Servlet to manage the users session and use CMT to manage the transactions. DHave an Entity Bean to represent the customer. Use a Stateful Session Bean to manage the users session and use CMT to manage the transactions.
As per my understanding correct answer should be D. But as mock test, C is correct answer. Please suggest.
if the ejb's are to be accessed directly, stateful beans will do the job, however, in most cases you will have a web application sitting on top of the core application. its easier to do it in the web-tier as the session object is made available to servlets by the webserver.
SFSB are heavy objects. They use much more resources rather than SLSB. The questions attemps that the site are going to be accessed by a huge number of customer, so, if each access from remote user needs to open a new fat object (SFSB) you could comprimise your EJB server with so much resources.
State in this case does not need to be transactional (user sessions) so, the transacional behavior could be isolated only in the Domain Model, which is, the Entity Beans maintained by the EJB container. When using Entity Beans, only CMT are allowed to be used, so the letter 'C' could be considered the finest answer for this question.
I'm not sure if it is conclusively proven that SFSB's are costlier than HttpSession as far as state management is concerned though it might seem that SFSB's would be costly. Here is one study which concludes that "cost of storing data in an HTTP session object is basically the same as using a stateful session bean". http://www.dev2dev.co.kr/pub/a/2002/10/zadrozny.jsp
Using Session beans you can manage the resources more gracefully than the session object as the stateful session beans provides the activation and passivation mechanism. Also, the customer is represented as entity bean, and it look that credit card processing is done using stateless session bean. I feel it is always better to keep session data closer to business logic processing.
The key for your provided article is that SFSB must be removed by the client after it used for some task. Regarding this removal process, the activation and passivation operations are still be performed in the application cycle.
So, in that case, this os the cost the SFSB brings to the solution, the passivation process. Swapping objects to the disk is an expensive process. The only way that an SFSB would never passivate is using every time in order to garantee that the Container should not think that it is obsolete. Wich means that, this is a performance issue to be mitigated.
Try to make a tunning of an Application Server to engage a more detailed resume about EJB resouce management. Do not truste in this articles, they can be very intrusive to promote more Application Server sales.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com