HttpSession access needed in EJB

Discussions

EJB design: HttpSession access needed in EJB

  1. HttpSession access needed in EJB (8 messages)

    Hi All,

    Is it possible to get at values that have been put on a HttpSession in a servlet from within an EJB. The reason is I need to log user actions. The user ID is stored in the Session variable and I need to persist it using a CMP Entity bean. So some where in the middle of an EJB I need this information. I am using a Stateless session bean wrapping an Entity bean to do the logging. I don't want to have to pass the ID around all my other EJB's just so I can log it.

    Any ideas....
    Cheers,
    JC

    Threaded Messages (8)

  2. HttpSession access needed in EJB[ Go to top ]

    hey JC,

    i dont think theres any way u can access the HttpSession object from your session bean. the only way to do what u wanna do is to pass the user id as a parameter to ur session bean method call

    kapil
  3. *throws yellow flag* BAD DESIGN... 10 YARD PENALTY...

    So you're saying you want your presentation-layer independent middle tier to contain code specifically for an HttpSession???


    If the SB doing the logging is stateless how will it know which HttpSession to call? You have to pass something to the SB, so why not the data you need.

    If the SB is stateful then just pass the ID to it upon creation and it can keep using that.

    I would opt for the stateful model.

    -JC ;)
  4. Cheers for the replys...I think you are right about the SB...If I use the stateful model then I just need to pass in the value...Can I then use getEJBObject() to get a handle for this statful bean in other EJB's

  5. HttpSession access needed in EJB[ Go to top ]

    You have to store the handle to the Stateful bean in your Session cache. If you lose reference to this handle, there is no way of getting it back. (can do this only with Entity EJB). Also, if you call any other Bean other than this Stateful bean, you have to pass in the reference to this Bean as an argument. (if you need access to the Stateful bean from within this other Bean)...

    Since you are talking about one simple parameter, why not try the Stateless model and send the user id parameter around? Avoid stateful beans, if you can. Stateless beans are highly scalable, since they use Instance pooling...
  6. HttpSession access needed in EJB[ Go to top ]

    Avoid stateful beans, if you can. Stateless beans are

    >highly scalable, since they use Instance pooling...


    Stateless beans are no more "scalable" than stateful beans, and both can be pooled. The distinction comes if/when activation/passivation of the stateful beans takes place.

    -JC


  7. HttpSession access needed in EJB[ Go to top ]

    Stateful beans are used when you have state information and assuming fixed available resources, a Stateless bean is highly scalable than a Stateful bean, because there is no I/O bottleneck. Pl. refer to "Mastering EJB" by Ed Roman, available for download from this site, Chapter 5. You are right in saying that Stateful beans are also pooled, but it is only a pooling "effect", since there will always be an associated I/O. Taken from this book: "With stateless beans, the EJB container is able to easily pool and reuse beans, allowing a few beans to service many clients".

    The only drawback is that you have to push client-specific data into a stateless session bean's method each time. In this case, since it is only the userId that gets pushed, I was suggesting the Stateless solution. This also frees you from having to worry about stateful bean recovery.
  8. Justin Van Vorst 2001-04-03 12:46:06.0. wrote:

    "Stateless beans are no more "scalable" than stateful beans, and both can be pooled. The distinction comes if/when activation/passivation of the stateful beans takes place."

    Not true.

    1) Stateful beans are typically not transparently fault tolerant in most of todays application servers, although I concede that I think WebLogic has made it with 6.0.

    2) Instance pooling is used for both, true. But when a remote stateful bean proxy is attached to a bean instance, the state of the bean must be set to match the client. You skip this step with a stateless bean. Since this is likely to be done with reflection it's not the quickest step in the world. Avoiding it is a good idea if you can.

    The spec isn't clear about whether or not multiple threads will run through a single instance of a stateless session bean, but in theory it could. However, a stateless session bean can still have non client specific state in it that you might need to synchronize. But that's not allowed by the spec, so in all probability the servers won't run multiple threads through.

    Stateless session beans aren't usually passivated or activated are they? There isn't much point since they store no client state. Again, non client specific state could be a factor.

    I would pass the user id into a stateless session bean.

    Chz

    Tony
  9. Justin Van Vorst 2001-04-03 12:46:06.0. wrote:

    "Stateless beans are no more "scalable" than stateful beans, and both can be pooled. The distinction comes if/when activation/passivation of the stateful beans takes place."

    Not true.

    1) Stateful beans are typically not transparently fault tolerant in most of todays application servers, although I concede that I think WebLogic has made it with 6.0.

    2) Instance pooling is used for both, true. But when a remote stateful bean proxy is attached to a bean instance, the state of the bean must be set to match the client. You skip this step with a stateless bean. Since this is likely to be done with reflection it's not the quickest step in the world. Avoiding it is a good idea if you can.

    The spec isn't clear about whether or not multiple threads will run through a single instance of a stateless session bean, but in theory it could. However, a stateless session bean can still have non client specific state in it that you might need to synchronize. But that's not allowed by the spec, so in all probability the servers won't run multiple threads through.

    Stateless session beans aren't usually passivated or activated are they? There isn't much point since they store no client state. Again, non client specific state could be a factor.

    I would pass the user id into a stateless session bean.

    Chz

    Tony