jQuery in Action, 3rd edition
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes SFSB session facade vs SLSB session facade Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide this week in the OCAJP 8 forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "SFSB session facade vs SLSB session facade" Watch "SFSB session facade vs SLSB session facade" New topic

SFSB session facade vs SLSB session facade

vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 192
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

Joined: Feb 18, 2005
Posts: 23
Hi Vu

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

vu lee
Ranch Hand

Joined: Apr 19, 2005
Posts: 192
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

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.


Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1183

"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�

Joined: Jul 12, 2005
Posts: 8

Originally posted by vu lee:
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.

[ July 14, 2005: Message edited by: Marcel Karombor� ]
I agree. Here's the link: http://aspose.com/file-tools
subject: SFSB session facade vs SLSB session facade
It's not a secret anymore!