Out of these two approaches, which one is better? 1) SFSB session facade --> SLSB 2) SLSB session facade --> SFSB
Many ranchers who passed the exam used the first approach. My doubt is that SFSB is per client. If a client just browses the product catalog, then SFSB instance will be waisted.
Albert Maurucier
Greenhorn
Joined: Feb 18, 2005
Posts: 23
posted
0
Hi Vu
Sun recommands SFSB as facade if the use case is conversational.
Regards Albert
vu lee
Ranch Hand
Joined: Apr 19, 2005
Posts: 189
posted
0
Albert, I am thinking about scalability issue. SFSB is not as scalable as SLSB. In case of SFSB, if 300 users browse a product catalog at a time, then 300 SFSB instances are created. If SLSB is used, probably 50 SLSB instances are needed.
David Follow
Ranch Hand
Joined: Oct 16, 2001
Posts: 223
posted
0
Vu,
why would you want SFSB in the first place? Have you ever thought about making the business tier stateless? This would make your app. easy to scale. You would then have to keep state in the client- and presentation-tier.
D.
SCJP, SCEA
Dan Drillich
Ranch Hand
Joined: Jul 09, 2001
Posts: 1121
posted
0
Vu,
"Core J2EE Patterns" the second edition speaks about this issue on page #47:
However, some designers choose stateless session beans, hoping to increase scalability, and they may wrongly decide to model all business processes as stateless session beans. When using stateless session beans for conversational business processes, every method invocation requires the state to be passed by the client to the bean, reconstructed at the business tier, or retrieved from a persistent store. These techniques could result in reduced scalability due the associated overhead in network traffic, reconstruction time, or access time respectively.
-- Dan
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Marcel Karombor�
Greenhorn
Joined: Jul 12, 2005
Posts: 8
posted
0
Vu
Originally posted by vu lee: Albert, In case of SFSB, if 300 users browse a product catalog at a time, then 300 SFSB instances are created. .
This isn't always true, many servers emulate SLSB life cycle, SFSB state is persited on disk betwen method calls and the SFSB instance is reallocated to another client. I agree that this solution has a drawback: intensice I/O read-write. SFSB don't scale well, entity beans are a performance bootleneck. this is true and false in the same time.The choices you make should depend on your system, a generic solution doesn't exist. Choosing the optimal solution is the hardest part of the architect' job.Often QoS requirements are orthogonal. Anothet thing to take im mind : we should find (tests, tests and tests...)the optimal server configuration for our system.I have seen many critical applications running inside servers with DEFAULT CONFIGURATION!! We should leverage all optimization startegies that modern servers provide.
0
