1

Context

Simple Java EE 6 (JBoss AS 7.1) CRUD Web App, Using a @Named backing bean, @SessionScope of JSF pages:

Question

Why would be a bad idea to store the HTTP session stateon the CDI bean? For example, storing the shopping cart items right there.

Comments

SFSB are meant for this, due to their conversational state, but I've read that they are not easy to use in practice. Also I think that another option would be the HttpSession object.

I'm also aware about the passivation/activation advantage that they hold.

Community
  • 1
  • 1
jacktrades
  • 7,224
  • 13
  • 56
  • 83

2 Answers2

3

I think you are confused between "session" as used for the HTTP session and as used for a session with a specific bean (the stateful bean in this case).

They serve different purposes, but also overlap. Originally, the session with a SFSB was used for non-HTTP remote clients (Applets and Swing applications). In a way you could say it was the RMI equivalent of the HTTP session.

When there's already an HTTP session available, it doesn't make sense to use stateful session beans for this purpose, and you'd be better of by using HTTP session scoped beans.

Stateful session beans do have their uses though, for instance they're able to accommodate the extended persistence context and can keep e.g. (optimistic) locks open outside of transactions.

When used in a Java EE 6 web application, you'd often want to assign the stateful session bean an HTTP session scope. Otherwise, even though the bean has an internal session, it's not connected to anything but to the proxy you use to communicate with it.

Also see:

Community
  • 1
  • 1
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • uff... Can you give me more info about extended persistence context? Assign the SFSB a @SessionScope... What is the advantage from just using a CDI bean for that? – jacktrades Dec 15 '12 at 12:21
  • 1
    The extended persistence context is a JPA context that is not bound (scoped) to a transaction, but to the lifetime of the stateful session bean. For a more elaborate explanation you could take a look at the book "Pro JPA 2". – Arjan Tijms Dec 15 '12 at 12:25
  • So to make things simple, if no extended persistent context' is needed, then I should stay off SFSB? – jacktrades Dec 15 '12 at 13:48
  • 2
    That's a bit too simple perhaps, but yes, the extended persistence context is a big use case. The bottom line is; if you need the specific capabilities of a SFSB don't shy away from it, but don't confuse their "stateful" abilities with the general notion of state in a web application. SFSBs are NOT in any way the normal mechanism to store web application state. – Arjan Tijms Dec 15 '12 at 14:09
  • To refrase Arjan: you should use SFSB when in addition to the state holding feature you need to use other session bean feature like transaction management (with JPA extended scope SFSB can have non one shot transaction like with the SLSB) or like authorization. If you only need moret than one request state, CDI is probaly more easy. – Kazaag Dec 16 '12 at 13:44
2

Here are the supposely benefits of SFSB:

  • SFSB are transactional.
  • SFSB can be passivated/activated.
  • SFSB enable extended persistence context.

The price to pay for these is that the exception scheme is more complex (rollback, non-rollback exception, etc.), the lifecycle as well, and by consequence debugging.

Usually, you don't need passivation/activation. To make the design scalable, store as little as possible in memory. Usually, extended persistence context aren't needed as well (they have their use, though).

However, requests must process in a transacted way. But you don't need SFSB for that. You can handle error and recovery yourself to make sure your HttpSession is consistent. Make sure you use transactions to access your backend, though!

ewernli
  • 38,045
  • 5
  • 92
  • 123