Discussions

News: Featured Article: Stateful Session Beans Rock

  1. Featured Article: Stateful Session Beans Rock (72 messages)

    Gavin King always thought that stateful session beans had scalability problems (since many people push this viewpoint). In this article he discusses looking into stateful session beans, and how he concluded that they don't have those problems at all.

    Excerpt
    Like, I suppose, many Java developers, I have so often read about the supposed scalability problems associated with stateful session beans, that I simply accepted that these problems were real, and refused to even consider using stateful beans. I guess this was laziness, but we don't have time to verify everything we read - and I'd never had cause to doubt that what I read was correct.

    A few months ago, as Christian and I were nailing down our notion of "application transactions" in a hotel room in Kohn Kaen, Thailand, it really struck me hard that a stateful bean is the perfect place to keep state associated with the application transaction. (An application transaction is a unit of work from the point of view of the user; it spans multiple database/JTA transactions.) For example, you could keep a dedicated Hibernate session for the lifetime of the stateful bean, obviating the need for detaching and reattaching the object graph at every request.
    Read Gavin King in Stateful Session Beans Rock

    Threaded Messages (72)

  2. Application Transactions[ Go to top ]

    Hi Gavin,

       I am assuming that your notion of an application transaction corresponds to what Fowler calls a business transaction.

       What sort of support are you looking at putting into Hibernate/JBoss for application transactions?
  3. Application Transactions[ Go to top ]

    Since Stateful Session Bean is also serialized, SessionFactory is,
    eventually , serialized whether it is manually serialized/or just bound by the State of the Bean. In case I am wrong does using a Stateful applies to * scenarios? Logically a Stateless Bean looks more "fit" for backend dirty work since it does not have any of web environment component's aspects.

    Faisal
  4. Application Transactions[ Go to top ]

    What happens in Thailand should stay in Thailand.

    b
  5. Application Transactions[ Go to top ]

    Varying degree of seriosity/focus in this thread... ;)
  6. have a look at this link:

    http://anti-freeware.tripod.com
  7. Hibernate is great and so is JBoss. I just don't want to mess with JBoss configuration when I don't have to. Is this a warning? My heart will sink. Do think about me when you decide to go that way.
  8. I can't see people going back and using CMP Beans because of Hibernate. Hibernate is better off used as it is,even, more simpler as in Spring. As a Jboss & Hibernate user , i can't see how jboss can offer a better use of Hibernate

    No harm intended!
  9. That did occur to me, however there is another problem that I think is more serious. Using session beans for hibernate means EJB container is mandatory. This will immediately make it unusable for a huge community. I dont think Gavin should go there.
  10. Man, then don't use SFSB, use your HttpSession if you don't have/want/need/use an EJB container. It's the same, that was the whole point of the blog entry.
  11. Man, then don't use SFSB, use your HttpSession if you don't have/want/need/use an EJB container. It's the same, that was the whole point of the blog entry
    So? The blog entry is attempting to sell the idea that sfsb's scale. That's a dangerous proposition and needs to be debunked.
  12. Man, then don't use SFSB, use your HttpSession if you don't have/want/need/use an EJB container. It's the same, that was the whole point of the blog entry
    So? The blog entry is attempting to sell the idea that sfsb's scale. That's a dangerous proposition and needs to be debunked.
    Please stop this bullshit of "An excuse to lock Hibernate into JBoss?" JBoss Inc. support covers all of our projects. It is not sold separately for each project. Besides, even if your ridiculous statement was true, buying support from JBoss Inc. is a choice and JBoss and Hibernate is still open source software.

    If you choose not to buy JBoss Inc. support is $0 + $0 = $0.

    Bill
  13. Man, then don't use SFSB, use your HttpSession if you don't have/want/need/use an EJB container. It's the same, that was the whole point of the blog entry
    So? The blog entry is attempting to sell the idea that sfsb's scale. That's a dangerous proposition and needs to be debunked.
    Please stop this bullshit of "An excuse to lock Hibernate into JBoss?" JBoss Inc. support covers all of our projects. It is not sold separately for each project. Besides, even if your ridiculous statement was true, buying support from JBoss Inc. is a choice and JBoss and Hibernate is still open source software.If you choose not to buy JBoss Inc. support is $0 + $0 = $0.Bill
    Man....is my grammar bad or what????
  14. Hibernate scales with people[ Go to top ]

    Man, then don't use SFSB, use your HttpSession if you don't have/want/need/use an EJB container. It's the same, that was the whole point of the blog entry
    So? The blog entry is attempting to sell the idea that sfsb's scale. That's a dangerous proposition and needs to be debunked.
    Please stop this bullshit of "An excuse to lock Hibernate into JBoss?" JBoss Inc. support covers all of our projects. It is not sold separately for each project. Besides, even if your ridiculous statement was true, buying support from JBoss Inc. is a choice and JBoss and Hibernate is still open source software.If you choose not to buy JBoss Inc. support is $0 + $0 = $0.Bill
    Bill, no BS intended. There's politics behind a great deal of good decisions, yet that's not my concern. I got used to Hibernate. Wrapping basic Hibernate actions in my own code alows me to read/write to the db in just few lines of code. I am a general contractor during the day. Some nights I spend improving my Quickbooks alternative. Hibernate governed by a CMP engine is not Hibernate for me anymore. And I tend to believe that this is the sentiment of many in spite of the soundness of this thread's argument. Never mind a couple of bucks for a good O/R mapping tool. I might still have the receipt for those JBoss PDF's. But I love the open source and wish to support it by using it.

    Regards.
  15. guh[ Go to top ]

    Hibernate governed by a CMP engine is not Hibernate for me anymore. And I tend to believe that this is the sentiment of many in spite of the soundness of this thread's argument.
    Honestly dude, it really helps to read and comprehend the original post before commenting. You have /completely/ misunderstood the whole point of this discussion.

    No-one has suggested making Hibernate dependant upon the EJB container, not to mention the CMP engine.

    Instead, it is a suggestion that a nice /application/ architecture would be to have stateful session beans mediate access to the Hibernate session.

    Since /you/ are the application architect, you get to decide.
  16. I understand that. What if I am not even using a servlet engine? Maybe I have a standalone database application. My only concern is that session concept should be appropriately abstracted so that I can still use it as a standalone product.
  17. What if I am not even using a servlet engine?
    Ok. For another example, maybe its a plain RMI servant.
    My only concern is that session concept should be appropriately abstracted so that I can still use it as a standalone product.
    Sure, I totally dig not wanting a container. I suppose it's straightforward (but tedious) to use a HashMap in the RMI servant that maps client IP address to an application session. AOP or other class enhancer might nicely encapsulate such a feature.

    Passivation of abstract sessions without a container could possibly be achieved by listening to the java.lang.ref Reference package for notification of imminent eviction; just a guess.

    Accomplish clustering without a container by object serializing to NFS for passivation on one machine and reactivation on another. AOP might automate the work that happens during object lifecycle transitions.

    I think I'm starting to understand how a container could be unnecessay if AOP can weave container features into POJOs. Self-service containment, in a sense.
  18. I can't see people going back and using CMP Beans because of Hibernate. Hibernate is better off used as it is,even, more simpler as in Spring. As a Jboss & Hibernate user , i can't see how jboss can offer a better use of Hibernate

    No harm intended!
    Although I strongly disagrees with Gavin on this point, I find no reason to question his integrity. Gavin is a cool and clever guy that cares about the community.
  19. Unfortunately, Gavin has missed the point about the scalability problems with SSBs.

    He says:

    "<blah,blah,blah>... Serializing it to the database is even worse."

    This is where he concludes without giving the premises. Putting state in the database is actually the only plausible solution in *large scale* systems - which is exactly the systems where scalability starts to matter. When you drive your topology to the max, EJB containers starts to employ what is called passivation. This means *transactional* disk I/O. And what subsystem excels at that? Databases, of course. I would NEVER EVER put state in SSB unless I have limited state in a non-clustered environment with less than, say, 100 concurrent users.

    Any non-trivial system, at least the ones I've worked on in the telco industry, collapses under the passivation scheme.

    There's a few things to consider and *test* when deciding where to put state:

    1. Topology. Is the web/fat client, application and db tiers on the same machine? If not, between what physical layers must state be serialized and what is the network latency if doing so?

    2. Memory consumption. Will the passivation process start frequently. What about garbage collection? If you have an SMP, can you set the GC thread affinity to a dedicated GC processor?

    3. How does *your* container perform activation/passivation?

    4. What about state replication? Usually not a problem, but in some huge systems, replication on the DB level makes sense and works flawlessly.

    Gavin says:

    "For example, you could keep a dedicated Hibernate session for the lifetime of the stateful bean"

    He's just moving the problem. You cannot scale without a sane resource dispenser. SSB's doesn't provide that.

    I am not saying SSB's are useless. They just doesn't scale, and I have first-hand experience with those problems in WL, WAS and JBoss. Not their fault that the spec sucks, though.
  20. I think you have a point about 'passivation' being a bottleneck for scaling. However, I think this applies to those applications where you have a very large number of active sessions which also keep getting requests frequently. This will cause a large rate of passivation and activation of the SFSBs (as all the SFSBs ,one representing each session, cannot be maintained in memory). In that case you could use an entity bean as your session object. Then, the database is used for holding the bean and you will get the high performance and scalability that is needed.

     However, there are a large number of apps where the average number of sessions at any point in time is bounded (and can be held in memory ). In addition there are apps where the number of sessions is very large (for example , a login to an email system like yahoo , which is held active for hours), but the number of requests per session is usually concentrated within a short time (during which time the session can be held in memory). I think SFSBs will scale well for these apps.
  21. However, there are a large number of apps where the average number of sessions at any point in time is bounded (and can be held in memory ).
    Well, how is scalability a consern if you have control over the bounds and everything can be kept in memory? This is scaling by "brute-force"... just add enough memory/hardware and off you go.

    This is unrealistic for most high-end systems (I'm talking telco/financial/medical here). Passivation *is* the crux of the problem and it is *the* fundamental flaw in the EJB specification.

    For hard core stuff: put state in the database; it's been working enourmously well since the 60's. Databases are optimized from storing and retrieving transactional state. It's why we have it. They can replicate. The can CRUD. They can do it the ACID way.

    There is a reason why CICS and IMS is still the preferred platform for serious stuff.

    You *can* make serious stuff work with EJB's and Hibernate, but you cannot possibly put a lot of state in the SSLBs.
  22. Keeping Session state in DB[ Go to top ]

    There is a reason why CICS and IMS is still the preferred platform for serious stuff.You *can* make serious stuff work with EJB's and Hibernate, but you cannot possibly put a lot of state in the SSLBs.
    Well, I've been a CICS system programmer for many years and I can tell you that a lot of Session-related state (user data, user preferences, state in the conversation, even data that would be committed to the DB at the end of a complex "business transaction") is abitually kept in memory or in support files (CICS offers several alternative services), not in the DB. And this typically happens in the CICS region running the Application code (i.e. mid-tier), not in the front-end.
    So I mostly agree with Gavin view. This kind of state is not truly 'persistent', in that it lasts only the duration of a user session.
    However, this complicates clustering and failover a bit, but that is a problem of container designers and should be kept transparent ot application developers.
    And the passivation mechanism, given a proper implementation and a good setting of the pools sizes, can really optimize resource consumption without penalizing too much the response times: it is analogous to swapping out users in a time-sharing environment, similar to what happens with virtual storage, a pattern very common and long proven for managing limited resources confronted with a variable and unpredictable load.

    Ciao
    Andrea
  23. Mahesh: .. This will cause a large rate of passivation and activation of the SFSBs (as all the SFSBs ,one representing each session, cannot be maintained in memory). In that case you could use an entity bean as your session object. Then, the database is used for holding the bean and you will get the high performance and scalability that is needed.

    No database can handle that load, if it cannot be handled by a cluster of well-tuned app servers. Dumping everything into the database is as naive as assuming that you can dump everything into SfSB's. Most scale-limited J2EE applications are limited because the database is the bottleneck.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  24. dear Cameron Purdy, gavin & others

    where can one find stuff relating to how various appservers
    handle sfsb's and whats wins at the end

    because i see from so many views put forth
    the key problem is this

    otherwise by better design and careful judgement
    sfsb related problems can be solved

    for example i have an application which needs to use sfsb
    on WAS 4/5, so i want to know if there are problems
    there

    can anyone help out?

    -sridhar
  25. Hi Sridhar,

    Sridhar: where can one find stuff relating to how various appservers handle sfsb's and whats wins at the end [..] otherwise by better design and careful judgement sfsb related problems can be solved [..] for example i have an application which needs to use sfsb on WAS 4/5, so i want to know if there are problems there

    What I have done in the past is build a test SfSB with no state (i.e. no memory used for "user" data) that implemented an empty Externalizable interface (no code in the readObject and writeObject methods). (If the no-op Externalizable implementation breaks it, remove that interface from your class and try to just implement the private readObject and writeObject methods as explained in the java.io.Serializable interface. If that doesn't work, just leave it as Serializable with no readObject or writeObject methods.)

    The first thing to understand is how big each SfSB is. Try creating 1000 inside a transaction. Stick the refs for each into an array. Create 1000. Create 2000. Create 10000. Make sure that the app server is tuned to have a "max in pool" setting much larger than your test is using. As part of the test, watch the memory consumption. Explicitly call System.gc() in the test and follow that with a Thread.sleep() call to give the garbage collector time to run. Monitor the memory with verbose GC or with a call to Runtime to find the total / free memory.

    Basically, you're looking for a pattern, such as:

    Before test: 25MB used
    After 1000: 30MB used
    After 2000: 35MB used
    After 10000: 75MB used

    So each 1000 uses 5MB, so each SfSB (with no "state") uses 5KB. (You will see much less memory than this consumed for most app servers.) The reason to test this is to determine how big you'll have to make the heap to handle a given number of SfSB instances, once the number is in the hundreds of thousands or even into the millions. (You can only predict the maximum number that the app will have active at any one time if the app uses them very explicitly and carefully, otherwise you'll easily leak SfSB instances and you'll end up overflowing your pool and passivating them.)

    Next, time those tests. How much does it cost to create and destroy 1000 SfSB EJBs? On some app servers, it is a fraction of a second. On others, it is more expensive.

    There are other things to look at, depending on how you plan to use the SfSB, such as how much it costs to look up a ref from a handle, how much it costs to passivate and activate SfSBs, how much it costs to invoke methods, commit transactions, etc. If your app has to passivate the SfSBs then you may want to avoid them altogether (IMHO) although it will probably still end up being more efficient and scalable than the alternatives, such as using a transactional data source (e.g. entity EJB).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  26. missed points[ Go to top ]

    Unfortunately, Gavin has missed the point about the scalability problems with SSBs.
    On the contrary, i think /you've/ missed /my/ point ;)
    He says:

    "<blah,blah,blah>... Serializing it to the database is even worse."

    This is where he concludes without giving the premises. Putting state in the database is actually the only plausible solution in *large scale* systems - which is exactly the systems where scalability starts to matter. When you drive your topology to the max, EJB containers starts to employ what is called passivation. This means *transactional* disk I/O. And what subsystem excels at that? Databases, of course. I would NEVER EVER put state in SSB unless I have limited state in a non-clustered environment with less than, say, 100 concurrent users.
    Well, there might be some occasions where it is better to serialize some state to the DB than it is do keep it in memory. But notice that this /is not current J2EE practice/! Current practice is to keep the kind of state that I am talking about /in the HttpSession/. Not the database.

    And if the performance characteristics of HttpSession state is similar to the characteristics of a Stateful session bean, then I would rather keep it in a stateful bean, if that is most convenient.
    Gavin says:

    "For example, you could keep a dedicated Hibernate session for the lifetime of the stateful bean"

    He's just moving the problem. You cannot scale without a sane resource dispenser. SSB's doesn't provide that.
    Sure, but I moved the problem to a place which is more convenient from the point of view of how I would like to implement my business logic. And, in addition, It removes a bunch of serialization between web and EJB tiers.


    The point of this post is actually not to say "move state from the DB to the middle tier". It is to say "stop moving state from the EJB tier to the web tier, if it is unnatural to do so".
  27. missed points[ Go to top ]

    Gavin says:
    Current practice is to keep the kind of state that I am talking about /in the HttpSession/. Not the database.
    That's what articles and books are selling you. But successful implementors of J2EE technology actually DOES use the database to keep state. For obvious reasons, as I've mentioned above (optimized for concurrency, transactional serialization and asynchronous I/O to reduce CPU load, caching, replication features, etc, etc).

    That said, Hibernate is perfect (for many applications) to actually orchestrate the prosess of maintaining state in the database. In other apps, you need to go lower level and sometimes drop Java altogether, but that's the extreme cases.
    The point of this post is actually not to say "move state from the DB to the middle tier". It is to say "stop moving state from the EJB tier to the web tier, if it is unnatural to do so".
    If that was the sole point, I'd agree.

    However, the scalability problems with stateful session beans still prevails. They are real, and they are due to the passivation mechanism + the non optimal Java serialization spec. Your post implies that the beans doesn't have scalability problems (folklore), but that's not true from my shops extensive experience with this stuff.

    You claim that stateful session beans rock. I say show me the evidence. I have presented evidence on the contrary.
  28. missed points[ Go to top ]

    Gavin says:
    Current practice is to keep the kind of state that I am talking about /in the HttpSession/. Not the database.
    That's what articles and books are selling you. But successful implementors of J2EE technology actually DOES use the database to keep state.
    On the contrary, very many successful applications keep state relating to the application transaction in the web session. This is just incredibly common. (And, indeed, for many kinds of applications it makes good sense.) It may not be what /you/ do, but I was not addressing the blog entry to you personally ;)
    The point of this post is actually not to say "move state from the DB to the middle tier". It is to say "stop moving state from the EJB tier to the web tier, if it is unnatural to do so".
    If that was the sole point, I'd agree.However, the scalability problems with stateful session beans still prevails. They are real, and they are due to the passivation mechanism + the non optimal Java serialization spec. Your post implies that the beans doesn't have scalability problems (folklore), but that's not true from my shops extensive experience with this stuff.You claim that stateful session beans rock. I say show me the evidence. I have presented evidence on the contrary.
    Indeed, that was 90% of my point. So I'm not sure what we are arguing about ;)

    And the evidence I showed was an actual paper which showed real numbers comparing the "scalability problems" of keeping state in stateful beans with the scalability of keeping it in the web session. And the paper finds no particular difference.

    I am certainly not disputing that you have once or twice implemented an application where you were able to increase performance by shifting state from a stateful bean to the database. But that does not mean that this would hold

    * for all kinds of state
    * for all kinds of application

    I am talking about a specific kind of state (state relating to the application transaction), that is usually kept in the HttpSession in existing applications.
  29. missed points[ Go to top ]

    Gavin said:
    I am certainly not disputing that you have once or twice implemented an application where you were able to increase performance by shifting state from a stateful bean to the database.
    Performance dropped actually (for the first few tens of clients), but it scaled much, much better, which is what I'm discussing.

    Performance and scalability are mostly unrelated.
  30. missed points[ Go to top ]

    han: However, the scalability problems with stateful session beans still prevails. They are real, and they are due to the passivation mechanism + the non optimal Java serialization spec. Your post implies that the beans doesn't have scalability problems (folklore), but that's not true from my shops extensive experience with this stuff.

    It all depends on the app server in use and the manner in which the stateful sessions are being used. With a relatively well designed app running in a well architected app server in a cluster, handling a couple million stateful session beans is no problem.

    Most of the issues with SfSB's is that the app server implementors took short-cuts when they implemented them. I could give specific examples, but suffice to say that they were all (at one time or another) atrocious, which is how statefuls got a bad name in the first place.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  31. missed points[ Go to top ]

    The point of this post is actually not to say "move state from the DB to the middle tier". It is to say "stop moving state from the EJB tier to the web tier, if it is unnatural to do so".
    But you still need to put your SFSB proxy in the HttpSession, for accessing it in later requests. Essentially, you have two states in different places then: your middle tier state in the SFSB, and your SFSB proxy in the HttpSession. Web tier code is responsible for fetching and removing the SFSB proxy. So you don't really get rid of middle-tier-driven state management in the web tier, do you?

    I don't see what benefits a local SFSB gives you for holding a Hibernate Session that you couldn't achieve with a simple state holder object in the HttpSession. In both cases, it's web tier code that manages the lifecycle of the respective state object. And with a simple state holder object, you just need HttpSession replication, avoiding additional SFSB state replication.

    Juergen
  32. missed points[ Go to top ]

    The point of this post is actually not to say "move state from the DB to the middle tier". It is to say "stop moving state from the EJB tier to the web tier, if it is unnatural to do so".
    But you still need to put your SFSB proxy in the HttpSession, for accessing it in later requests. Essentially, you have two states in different places then: your middle tier state in the SFSB, and your SFSB proxy in the HttpSession. Web tier code is responsible for fetching and removing the SFSB proxy. So you don't really get rid of middle-tier-driven state management in the web tier, do you?I don't see what benefits a local SFSB gives you for holding a Hibernate Session that you couldn't achieve with a simple state holder object in the HttpSession. In both cases, it's web tier code that manages the lifecycle of the respective state object. And with a simple state holder object, you just need HttpSession replication, avoiding additional SFSB state replication.Juergen
    Well, can the HTTPSession do transaction demarcation? Can the HTTPSession get callbacks and be registered with the TM?

    Bill
  33. Why?[ Go to top ]

    I don't see what benefits a local SFSB gives you for holding a Hibernate Session that you couldn't achieve with a simple state holder object in the HttpSession. In both cases, it's web tier code that manages the lifecycle of the respective state object. And with a simple state holder object, you just need HttpSession replication, avoiding additional SFSB state replication.Juergen
    The benefits apply to a topology with physical separate web and EJB tiers. In that case, we would be able to avoid some serialization between tiers.

    Certainly, in this scenario, we cannot keep the Hibernate Session in the HttpSession, because we shouldn't serialize the Hibernate Session between tiers - it is too big for that. So normally, people use detached objects in this architecture. But there are performance and other advantages to using long sessions instead of detached objects.

    :-)
  34. Why?[ Go to top ]

    I have never seen the alternative to SFSBs being to stick the entire state into the HTTP session. I have see the alternative being to stick an index into the session and the state into say an entity bean with optimistic concurrency. The motivation is entirely cluster-motivated since this state can be propagated across as many nodes as you wish whereas there have been limitations as far as the SFSB is concerned.
  35. Why?[ Go to top ]

    The benefits apply to a topology with physical separate web and EJB tiers. In that case, we would be able to avoid some serialization between tiers.
    I absolutely see the point when using remote SFSBs: There's no point in holding a Hibernate Session in a physically separated web tier. However, my point was specifically about local SFSBs: In general, I'm not convinced that using local SFSBs in a web app is preferable to simple state holders objects in HttpSessions in typical web app scenarios.
    Well, can the HTTPSession do transaction demarcation? Can the HTTPSession get callbacks and be registered with the TM?
    Well, does a Hibernate Session holder object need transaction demarcation? Does it need callbacks and registration with the TM? I'd rather design it as a simple holder object, to be accessed by otherwise stateless business objects - if I choose to use long Hibernate Sessions at all, which can often be avoided, sticking to transaction-scoped Sessions.

    Juergen
  36. Why?[ Go to top ]

    I don't see what benefits a local SFSB gives you for holding a Hibernate Session that you couldn't achieve with a simple state holder object in the HttpSession. In both cases, it's web tier code that manages the lifecycle of the respective state object. And with a simple state holder object, you just need HttpSession replication, avoiding additional SFSB state replication.Juergen
    The benefits apply to a topology with physical separate web and EJB tiers. In that case, we would be able to avoid some serialization between tiers.Certainly, in this scenario, we cannot keep the Hibernate Session in the HttpSession, because we shouldn't serialize the Hibernate Session between tiers - it is too big for that. So normally, people use detached objects in this architecture. But there are performance and other advantages to using long sessions instead of detached objects.:-)
    I'm not going to get into the usefulness of stateful beans on a general basis, but I want to question if they actually really make sense for holding the Hibernate Session?

    If the Session is used, and throws an Exception, it's generally not supposed to be used any longer as it's not in a valid state. This is not generally a problem in the way that most people use Sessions right now, i.e. manually opening a session before use and closing it afterwards, or using a Thread bound session which encompasses a bunch of session related operations lower down, since an exception will bring you back up the stack, and subsequent requests from the view layer will result in the creation of a new session. But with the session in the SFSB, you now have to catch all Hibernate related exceptions, but not other exceptions, and make sure the Session is reset properly (ie create a new one and store it in the SFSB). I can see this as being somewhat of a pretty big hassle and/or error prone, unless all Hibernate operations are going through a few very well defined points. (In this respect, something like a modified version of Spring's HibernateTemplate, used everywhere, would probably be a lot less error prone than hand-rolled code). Goofing this up is not something you are going to catch until an exception actually happens in real use. At that point, the whole app blows up permanently for the use.

    Am I missing something?
  37. Why?[ Go to top ]

    I can see this as being somewhat of a pretty big hassle and/or error prone, unless all Hibernate operations are going through a few very well defined points. (In this respect, something like a modified version of Spring's HibernateTemplate, used everywhere, would probably be a lot less error prone than hand-rolled code). Goofing this up is not something you are going to catch until an exception actually happens in real use. At that point, the whole app blows up permanently for the use.Am I missing something?
    You are right, it is error prone. But it is JDBC connection is error prone the same way too. You will have no problems if you will think about stefull bean by
    JDBC connection analogy, transaction/connection per thread. Stefull bean can be used in the same way, this analogy valid for any "resource".
  38. Why?[ Go to top ]

    Sory, I have said too mutch "this analogy valid for any "resource", I wanted to say: this analogy valid for any not thread safe resorce in multithreaded application.
  39. Why?[ Go to top ]

    I can see this as being somewhat of a pretty big hassle and/or error prone, unless all Hibernate operations are going through a few very well defined points. (In this respect, something like a modified version of Spring's HibernateTemplate, used everywhere, would probably be a lot less error prone than hand-rolled code). Goofing this up is not something you are going to catch until an exception actually happens in real use. At that point, the whole app blows up permanently for the use.Am I missing something?
    You are right, it is error prone. But it is JDBC connection is error prone the same way too. You will have no problems if you will think about stefull bean by JDBC connection analogy, transaction/connection per thread. Stefull bean can be used in the same way, this analogy valid for any "resource".
    I don't think it's quite the same as a connection at all, because most appservers like Jboss or WebLogic will pick up on the fact that you didn't close a connection obtained during a JTA transaction, and close it for you when it is done, probably with a logged warning message. And in any case, people do forget to close connections all the time (putting in another plug for Spring, it's automated connection handling is great in this respect). With the session handled in this fashion, people could run production code for a long time without knowing there is a bug, until one exception in the right spot kills subsequent session access for that user...
  40. Why?[ Go to top ]

    I don't think it's quite the same as a connection at all, because most appservers like Jboss or WebLogic will pick up on the fact that you didn't close a connection obtained during a JTA transaction, and close it for you when it is done, probably with a logged warning message. And in any case, people do forget to close connections all the time (putting in another plug for Spring, it's automated connection handling is great in this respect). With the session handled in this fashion, people could run production code for a long time without knowing there is a bug, until one exception in the right spot kills subsequent session access for that user...
    App server manages connections and it is error close managed DB connection, but user must commit "UserTransactions" and remove statefull beans himself, statefull bean is app server connection like JDBC connection is a database connection. Both app server and db have resource limits and any resources must be released ASAP and can not be used concurently. If app closes JDBC connections then it doe's not nesary means app is scalable, it must release all resources ASAP to scale (sockets,files,semaphores,memory, ....)
  41. Why?[ Go to top ]

    And the scalability law is very trivial: Do not waste resources.
  42. Why?[ Go to top ]

    And the scalability law is very trivial: Do not waste resources.
    Really? Bubblesort doesn't waste much resources, but it certainly doesn't scale.

    The "scalability law" is not trivial at all.
  43. Why?[ Go to top ]

    And the scalability law is very trivial: Do not waste resources.
    Really? Bubblesort doesn't waste much resources, but it certainly doesn't scale.The "scalability law" is not trivial at all.
    It scales, if you know where to use it.
  44. missed points[ Go to top ]

    But you still need to put your SFSB proxy in the HttpSession, for accessing it in later requests.
    Why? To reconstruct a stateful proxy per request, what information is needed other than the name of the interface and the session id? Both of these could easily travel as a parameter on the HTTP request (along with the action the user triggered and any needed arguments). Essentially session ID is the EJB handle (or part of it).

    Is there an EJB container that supports this type of design?
  45. missed points[ Go to top ]

    To reconstruct a stateful proxy per request, what information is needed other than the name of the interface and the session id? Both of these could easily travel as a parameter on the HTTP request (along with the action the user triggered and any needed arguments). Essentially session ID is the EJB handle (or part of it).
    AFAIK, you need to keep a reference to the actual SFSB proxy handle: There is no portable way to reaccess an active SFSB instance without having its handle. You could try to serialize the handle into a hidden HTML field to avoid keeping it in the HttpSession, but in any case: My point is that you can't avoid having to deal with this middle-tier-driven state in the web tier in some way.

    There is a point that local SFSBs complement a business layer that's otherwise built on local SLSBs: Passing a HttpSession-kept Hibernate Session to a local stateless EJB isn't desirable. But if your local business layer is built on POJOs, a simple holder object in the HttpSession will be the natural choice (or a HttpSession-scoped service POJO that holds the resource).

    Client-specific state on a physically separated remote server is a different matter: You do need remote SFSBs or a similar stateful remoting mechanism there. Such internally distributed applications are the original target area of EJBs: the area where they are able to show their full power. After all, colocated apps are not what EJBs were designed for in the first place.

    Juergen
  46. Discuss User Session in DB Further?[ Go to top ]

    Hi, Han.

    I'm not sure if you'll ever see this, but I'd like to talk to you about your experiences using a database to store the user session.

    I didn't want to post my email address (and I'm sure you don't either), so I created a Yahoo group for a discussion. That way, we can exchange email if we like, or just discuss it there (if you click on a person, you can send them email, without ever seeing the address).

    The group is "user_session_db · User Session in the Database".

    Are you interested?

    --Kevin
  47. i see that there is so much stuff in these threads
    and there is also too much of crap.
    annoying and personalizing comments
    what diff is this from a junk chat room
    please maintain standards.

    also most people who look for good stuff in these threads
    should send a request to the serverside

    a group of people who decide that particular person
    is annoying should send his login name based on which he should be debarred from the site FOREVER

    please take up this idea
  48. Usage has limited scope[ Go to top ]

    Interested thoughts. I don't know about the scope. Don't you think the scope using SFSB is somewhat limited to certain kinds of applications.

    When building applications involving long business transaction and multiple clients (roles in an organisation, actors in a system), a SFSB approach would not work IMHO. Nice and all that you don't have to deattach the object graph, but instead keep your Hibernate Session around longer, but I'm wondering how you will support multiple users interacting with the same object over and over when using such an approach. For example, selling something is a business transaction, involving two parties, of which either one of them has responsibilities and has to take actions. How would you model such a transaction?

    The same system: now involving long transactions but then only one user is involved in each transaction. Still, I don't want to loose my state. So I have to get myself a failover SFSB setup which would involve multiple (physical) machines and a cluster? Maybe the application is small, doesn't even need this when just launched.

    Application left are
    1) the ones not in need of state recovery, redundancy or failover (like someone else is already stating in a different reply) or
    2) the ones that from the beginning on already require it (failover, clustering, big ass machines) and don't have too complex business transaction involving more than one actor per transaction. Still the question is whether or not clustering schemes of different application servers are advanced and efficient enough at (transactional) state synchronisation to beat a database there.

    Am I wrong?
  49. An application transaction is a unit of work from the point of view of the user; it spans multiple database/JTA transactions.
    Imagine typical online store: users browsing goods and filling the shopping cart. What would you call each small act of shopping cart update? Is it an application transaction? A subtransaction?

    What is the point of storing the shopping cart in the database each time it is updated, if the user can easily change his mind and discard the whole purchase? It is not a life and death matter if this semi-persistent object would be lost or damaged. If a user lose his shopping cart, his credit card would not be charged, so he is officially fine. These losses should not happen often anyway, this why we pay thousands for app servers.

    The whole shopping process updates only an in-memory object, no database updates are made. Only when a user is ready to make a purchase web server switches to ssl and shopping cart is persisted in the database before the card is charged (we want to display it one last time and we want to be sure what a user is paying for). Well, even this database update can be avoided if PO would have some sort of checksum. Thus, the whole shopping process would consist of only one database transaction in the very end, including storing the cart and charging the credit card. This is basically a write cache, explicitly controlled by an application.

    The same goes with wizard-like browsing. The wizard data is collected into memory object and is flushed to the database in the end. Works fine for me. Granted, I did not work in telco with enormous databases. But these systems usually have a lot of short transactions, and most of them, apparently, are inserts, so I would write them directly to the database. Why did I write all this? I don't know, probably just to share my feeling that I do not feel comfortable spanning several database transactions during one app transaction. App servers costs about the same as database servers and I expect pretty good reliability from them, which is why I prefer to store a lot of data in session objects, and submit them to database in the very end in one transaction.

    I would store in the database only the data that I am sure about, like information about a new employee, who is already known to become an employee. Adding other information like address or previous jobs would be just an update operation. I do not like to store temporary data in database, I don't like when my database grows too much. I do not like cleaning it either.

    Passivation? Well, if we access the object ten times, we can deal with at most ten passivations. What if we store the same data in the database each time we modify it? We would issue ten database updates. What is faster? And what is the median passivation rate for a particular system? I'd say it is less than ten. So, I think that even with passivation we can save on number of database updates, either direct ones from the application, or indirect, through the app server passivation mechanism.
  50. For example, you could keep a dedicated Hibernate session for the lifetime of the stateful bean, obviating the need for detaching and reattaching the object graph at every request.
    I think the above quote is certainly interesting especially since the paper referred to in the blog seems to point out that the cost of storing something in the HTTPSession and in the Session bean seem to be similar. It should be noted that under Hibernate's implementation of optimistic locking, the easiest approach is to keep a session active on a per "application transaction" basis. Thus the above solution makes hibernate a little more easier to use than otherwise.

    However I have seen early developers often being tempted by the session as a nice catch-all place for all kinds of stuff and thats something to be careful about. The overhead of session maintenance is clearly related to the number of concurrent users, the actual size of data stored in the session, and configuration of persistent sessions / session failover.

    The above recommendation is indeed useful for hibernate developers. However I wouldnt go far as to say that Stateless Session Beans Rock.

    Dhananjay
  51. Stateful Session Beans Rock ?[ Go to top ]

    As far as I can see this article is intended to show that it is rationally to store the state
    in the middle tier, along with the business logic, where it belongs.
    I don't think so,but this post is dedicated to another problem. What about client calls serialization (I mean synchronization calls to the same instance). EJB Specification states the following:
    Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business
    method is in progress on an instance when another client-invoked call, from the same or different client,
    arrives at the same instance of a stateful session bean class, the container may throw the
    java.rmi.RemoteException to the second client[4], if the client is a remote client, or the
    javax.ejb.EJBException, if the client is a local client. This restriction does not apply to a stateless
    session bean because the container routes each request to a different instance of the session bean
    class.
    It means that project architecture should assume synchronization of calls to the same SSB instance (as it done in BluePrints application using public static synchronized methods - but it's not a solution in clustered environments).
    In my practise I participated in one project (for consulting and refactoring) where stateful beans were widely used. Stateful conversation design was very poor, the pool of session beans grew to unacceptable size. Unsynchronized calls to stateful beans from the same session led to "No Concurrent Calls to EJB" EJBException thrown by the container (you guess it was JBoss ;)... Some containers (like WebLogic) allows to specify calls serialization type in deployment descriptor, but it's not a rule).
    Sometimes the use of this kind of EJB is very effective, but SSB should be used carefully.

    Best Regards,
    Theodore V. Kupolov
  52. So you guys got a flight to Thailand, get a room from a hotel, every option is available to you, and what do you do... spend your time thinking about application transactions?!

    That is just wrong.
  53. It's a good call!
  54. So you guys got a flight to Thailand, get a room from a hotel, every option is available to you, and what do you do... spend your time thinking about application transactions?!That is just wrong.
     
      Exactly, thats what I thought ! :0)
  55. There is nothing wrong if scalability is not requared and there is nothing wrong with "application transaction" for single user applications
  56. I tried binding an HibernateSession to each thread in pool for life time of the thread, but failed. One cannot use an HibernateSession across transactions, as commit or rollback is going to invalidate the Proxy Connection associated with the HibernateSession.

    So you can definitely use HibernateSession cache, in SFSB, but not across transactions. comments are welcome....
  57. Long Sessions[ Go to top ]

    I tried binding an HibernateSession to each thread in pool for life time of the thread, but failed. One cannot use an HibernateSession across transactions, as commit or rollback is going to invalidate the Proxy Connection associated with the HibernateSession.So you can definitely use HibernateSession cache, in SFSB, but not across transactions. comments are welcome....
    The Hibernate session has methods called disconnect() and reconnect() that are used to disassociate the session from the JDBC connection. Please refer to the Hibernate documentation.
  58. Reality vs. simple answers[ Go to top ]

    My deepest respect to Gavin for creating Hibernate. Here are a few of my thoughts on the particular topic:

    I agree with Gavin in that there is an unjustified aversion to using stateful session beans in any scalable/high transaction-rate system. However, I find his conclusion to the direct opposite, in turn, to be a bit simplistic. Here's why:

    The number of simultaneous users supported and the average requet response time always have an inherent contradiction, since the fastest system will always be one which has everything loaded into memory, whereas you will need an infinite amount of memory to support an infinite number of simultaneous users. Thus, I reckon, the term scalability - maintaining the average response time as the number of simultaneous users increases. Also, which is important to my reasoning below, is that this implies that a system with fast response time is not necessarily a scalable system and vice versa.

    And here is my first point. Peter's paper on using HTTP session objects vs. Stateful session beans is on "performance", which I feel is generally a more fuzzy term, but in his papers primarliy revolves around response time and CPU utilization. As for scalability and number of users supported it does not really say anything other than for a certain amount of users, it seems to be the same whether using stateful session EJBs or the HTTP session for storing the same amount of info, and as the number of simultaneous users increases, the average response time increases even more.

    The latter indicating that scalability might be inoptimal, and at any rate not really "debunking" the scalability myth of stateful EJBs. What it proves though, which is also the point of the study, is that under the conditions accounted for, stateful session beans and HTTP session storage provide roughly the same "performance" - response times, CPU utilization and scalability.

    Also, Peter concludes that the difference is dramatic between letting the container handle the passivation of the stateful EJBs vs. performing an explicit ejbRemove, aided by the session listener mechanisms in his example. That is, in our (real-world) application we need to determine, as soon as possible when to remove an inactive stateful EJB instance from memory to make room for an active one. If not, performace will suffer badly.

    Think about that for a moment. In a web application, when do we know when a user has left the building, so to speak? The only two things I know of is when he/she performs an explicit logout (how many users do that before leaving your site?) or (by using the HTTP session listener interface) when his/her session times out.

    In the latter case, Peter uses an HTTP session timeout of 5 seconds(!). Not in any way to say that his results would be invalid because of this, but it firstly proves my first point of the perils of drawing real-life conclusions (about stateful EJBs vs. stateless EJBs/techniques scalability) from an artificial (and excellent and highly relevant) test on performance in the context of two stateful techniques vs. one another.

    Also (my second point), it shows that real life on the web is highly unpredictable and for a massive online site, the concept of storing everything in stateful entities (as in stateful session beans, on the HTTP session or in a regular static memory construct) is inherently not scalable and the ideal case of being able to clean all your instances (remove vs. passivate) in 5 second intervals, and thus to always provide enough free memory, is utterly unrealistic.

    Granted, here is where the need for container-provided mechanisms and life-cycle services, such as passivation, comes into play. But this is something that Peter's study shows gravely degrades throughput as the number of users increase - memory usage vs. throughput, or if you will, number of users vs. response time.

    As Peter also points out, the main culprit here is the passivation mechamisms mandated by the EJB spec, where memory space has to be provided by temoprarily removing possible active users' session state, and where serialization and disk I/O have to be performed, both costly operations. I am not a container developer, but I would think that a clever mechamism where the EJB state is mapped and written to a database (if needed), utilizing piggy backing and other I/O mechanisms optimized for decades, and performed at a point determined by clever configuration and dito algorithms would better meet real-life requirements. Then again, I don't know if that is allowed by the spec. Anyone?

    And so my final conclusion: Real-life problems seldom have room for simple answers, but need to be addressed by a best-of-both-worlds approach. Then again, I understand the emotional need for fighting fire (unjustified conclusions and myhths) with fire (aggresive headlines ;), but in the long run I believe that probably only bites back and fuels the somewhat religious tendencies of our industry to commit oneself to a certain technique or product, no matter what.

    Peace and successful deployments to you all.

    /Par
  59. Reality vs. simple answers[ Go to top ]

    I would think that a clever mechamism where the EJB state is mapped and written to a database (if needed), utilizing piggy backing and other I/O mechanisms optimized for decades, and performed at a point determined by clever configuration and dito algorithms would better meet real-life requirements. Then again, I don't know if that is allowed by the spec. Anyone?
    Container can use any method (which is Serialization compatible) to save the state of SFSB. Also any storage type (including database0 can be used. So it's just a matter of container. Should be not so harD to write such thing for JBoss by yourself.

    The container performs the Java programming language Serialization (or its equivalent) of the instance’s state after it invokes the ejbPassivate method on the instance.
  60. Reality vs. simple answers[ Go to top ]

    Container can use any method (which is Serialization compatible) to save the state of SFSB. Also any storage type (including database0 can be used. So it's just a matter of container. Should be not so harD to write such thing for JBoss by yourself.
    And this is part 2 of the problem with EJB's passivation scheme. Serialization is at averate an O(n^2) operation, using reflection. *THAT* doesn't scale to well either. But more serious is the fact that no container use transaction, high-performance databases for passivating objects. The mapping would be too slow.

    Put your state in the database. It makes sense. It works. It scales because databases scale extremely well under concurrent pressure.

    Gavin is dead wrong on this one.
  61. wierd[ Go to top ]

    han theman:

    All of your posts here ONLY make sense if, in addition to telling everyone "never use stateful session beans", you are /also/ telling them "never use the HttpSession".

    I dunno man, I think you will have a hard time convincing J2EE community to not put stuff in the web session.
  62. wierd[ Go to top ]

    Gavin claims:
    All of your posts here ONLY make sense if, in addition to telling everyone "never use stateful session beans", you are /also/ telling them "never use the HttpSession".

    I dunno man, I think you will have a hard time convincing J2EE community to not put stuff in the web session.
    I am NOT saying anything about HttpSession - at least that was not my intention. Show me the post where I'm claiming this.

    My focal point is stateful session beans and scalability problems. I'm debunking your blog entry.

    I have also not said "never use session beans". I am saying you need to understand the upper bounds in terms of scaling, and that the bounds are quite low because containers does not provide load conditioning and transactional, concurrent state management the way databases do.
  63. wierd[ Go to top ]

    All of your posts here ONLY make sense if, in addition to telling everyone "never use stateful session beans", you are /also/ telling them "never use the HttpSession".
    I'm probably getting noisy here, but HttpSession and SFSB's are different beasts. The web tier is usually easy to loadbalance and replicate. The business tier, with it's physical ties to resource dispensers (i.e JCA connectors, db connections, etc), are MUCH harder to scale up.

    Besides, not all applications out there are web applications. There's a lot of potential architectures, of course, but SFSB's should usually not be used in any of them.
  64. wierd[ Go to top ]

    The web tier is usually easy to loadbalance and replicate.
    Keeping the load balancer out of the question for now -- where's the difference in replicating the state of a SFSB vs. HTTPSession, and why do you think replicating the SFSB is harder than an HTTPSession?
  65. wierd[ Go to top ]

    han theman:All of your posts here ONLY make sense if, in addition to telling everyone "never use stateful session beans", you are /also/ telling them "never use the HttpSession".I dunno man, I think you will have a hard time convincing J2EE community to not put stuff in the web session.
    Staefull bean lets to demarcate transactions on client and it is
     very usefull, but it is a not good way to store session bean in http session both have nothing in common.
    Probably names "session" confuse, but transactions, connections are not designed to be used by multiple threads and to be "open" for half an hour, HttpSession is.
    It is better to forget "application transaction", it can produce very complex problems and I am sure this way can not scale (I have used a lot of antipatterns myself).
    I think it is good you are trieng to experiment and to find a way to fight with HTTP, but I think HTTP will be a winner :)
  66. application transactions work[ Go to top ]

    Staefull bean lets to demarcate transactions on client and it is very usefull, but it is a not good way to store session bean in http session both have nothing in common.Probably names "session" confuse, but transactions, connections are not designed to be used by multiple threads and to be "open" for half an hour, HttpSession is.It is better to forget "application transaction", it can produce very complex problems and I am sure this way can not scale
    Jouzas, wait 'till our book is out, we will show you exactly how to manage application transactions safely. There are solutions for the problems you are speculating about. The solutions are not even that complex.

    I've worked with a couple of customers who are using this kind of approach in real applications and it is absolutely workable.
  67. application transactions work[ Go to top ]

    Staefull bean lets to demarcate transactions on client and it is very usefull, but it is a not good way to store session bean in http session both have nothing in common.Probably names "session" confuse, but transactions, connections are not designed to be used by multiple threads and to be "open" for half an hour, HttpSession is.It is better to forget "application transaction", it can produce very complex problems and I am sure this way can not scale
    Jouzas, wait 'till our book is out, we will show you exactly how to manage application transactions safely. There are solutions for the problems you are speculating about. The solutions are not even that complex.I've worked with a couple of customers who are using this kind of approach in real applications and it is absolutely workable.
    It will be interesting to see, but it is better not to recommend it as the way to develop web applications.
    It must be better to find the way without "application transactions" first and to use workaround if thre is no way. Some good ways are proposed on this forum and I found it is always poossible to implement any use case in practice without resource mapped to http session.
    So why do you need application transaction, if it is not a trandaction ?
  68. Hibernate Container[ Go to top ]

    How about creating a purpose built transactional container for Hibernate!
  69. Hibernate Container[ Go to top ]

    How about creating a purpose built transactional container for Hibernate!
    See http://www.hibernate.org/110.html (specifically sections 5-7).

    Spring handles Hibernate Sessions in the context of its transaction abstraction (session-per-transaction, also supporting session-per-request). No dedicated support for "application transactions", though: I agree with Juozas that it's better to stick to a Session per database transaction (or per web request, if using the Open Session in View pattern).

    Juergen
  70. Right or Wrong?[ Go to top ]

    It seems that a lot of people seems to be missing the point about the advantages of SFSB.

    SFSB, are about manageability... not just scalability. The big advantage of SFSB is that you can choose how many will be in memory at any given time. This give you the ability to increase reliability in your system.

    If you have an application that runs well with say 1000 simultanious users. Now, for some reason you sudenly have an increase to 100000 simultanious users.

    In that situation, if you use HTTP session to maintain most of the state of a particular user (and say that CPU wise, you can handle that many requests), you are at risk of getting out of memory exceptions. Why, because you cannot easily manage the number of HTTP sessions that will be kept in memory. You will also get more frequent garbage collection. This situation may render you app server completely unsusable... It may event crash.

    Now if you use SFSB, you can actually set a maximum on the number of instance you have in memory. In the above situation, your server will probably start eating more CPU and doing more IO due to passivation. On the other end, it will still function properly because the amount of memory used will be kept under control. In that situation, when you start noticing the increase of hit on the server, you can decide to increase the number of some SFSB in memory and decrease the number of some other SFSB. This way, you can actually manage your server in real time. It should not even be that hard to write component that will monitor the usage of your application to help you decide which SFSB is more sollicited and give more resources to that one.

    Now I'm not saying that Http Session are bad and that SFSB are good. It's probably a good idea to keep state that is closer to the presentation in the Http Session and state that is closer to the business tier in a SFSB.

    Scalability and reliability are complex issues. One solution is never the best one for every problems. People, who say that SFSB are always bad, are wrong. People, who say that SFSB are always good, are also wrong.
  71. Good discussion, first of all. It is funny to read all the myths and concerns around SFSB. I agree that, if scalability matters, then SFSB can not be a good option. But most of the time there is a dozen or more factors that can influence the Architectural decission.
    From my perspective, SFSB are a very good option if complex transactions and/or workflow is needed in your project. My experience with first class application servers tells me that SFSB IS an option in a clustered environment. Stateless components can sometimes create unnecesary overhead on the data layer if state is needed because of complex business logic. And boys, sometimes we find ourselves implementing solutions to persist the state in the database, when some application servers allow us to do it almost 'magically' thanks to Stateful EJBs.
    Nice and healthy discussion.
  72. Long Sessions[ Go to top ]

    The Hibernate session has methods called disconnect() and reconnect()
    > that are used to disassociate the session from the JDBC connection.

    Does this allow an object to be in multiples sessions?
    This is a major problem i had with hibernate because common
    objects would be used from multiple threads.
  73. All is nice as long as you deploy on a simple - one node server.

    In real world you have to account for replication related network and serialization latency whenever clusters (for scalability) are involved.
    Most of WLS 6/7/8 based production deployments that I know use in one way or the other cluster based deployment topologies to fit these extra 100-200-300 concurrent users.

    In a "session replicated" cluster if you were to replace HTTP session with a state full EJB that has an equivalent setAttribute/removeAttribute methods you're toast - each modifying call to an EJB results in a asynchronous (or synchronous) data marshalling activity across the net to store new EJB state on another node (depending on replication policies) - container is not smart enough to marshal only a portion of your bean.

    This results in the entire user session data being transferred just because one attribute has changed.

    If HTTP session was to be used however, a single "setAttribute" call results only in "synchronization" of that one attribute's value and nothing more - much more efficient and adds up to better overall distributed resource utilization.

    best,
    -m.