SFSB session facade vs SLSB session facade

[vu lee]

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]

Hi Vu

Sun recommands SFSB as facade if the use case is conversational.

Regards
Albert

[vu lee]

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]

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.

[Dan Drillich]

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

[Marcel Karombor�]

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.

Marcel
[ July 14, 2005: Message edited by: Marcel Karombor� ]