Passing along our own context

Discussions

EJB design: Passing along our own context

  1. Passing along our own context (8 messages)

    Hi all,

    We need to have our own context passed along during a client call to the server. This context typically contains user information, current language setting, timezone and some other things. Do you guys know of any way to pass along this context during a call?
    The client will always call a session bean (stateless) and from there on we need to have access to this context no matter what other beans we might use during the call. Of course, the obvious solution would be to add an extra argument (ctx) to all our methods but we REALLY do not want that...

    Regards,
    Marcus

    Threaded Messages (8)

  2. We faced this exact sitution with our application many months ago. We thought it should be possible to put user level things in the JNDI context and retrieve them in a way similar to the way you retreive the caller identity, but after much research we never found a way to do it. We just added a parameter...I feel your pain.

    --Steven
  3. we had the same problem. Worse, we had our own session management layer. We ended up writing a custom security realm for weblogic and jboss that passed the session id as the JAAS Principal. Although it is a shorter lived Principal than you would normally think of, it is a valid way of looking at things.

    The server code could then get the principal off of the EJBContext and then use that to lookup the session info (locale, etc.)
  4. Passing along our own context[ Go to top ]

    This may or may not help you but IBM's Websphere Enterprise Edition includes a "work area" service that is designed just for this purpose.

    A solution that I have used within a single VM, is to have the first bean put info into a global Hashtable keyed by thread Id. The other code invoked by this thread can pick the info up, and the first bean can clean it up at the end.

    I understand the need for a service like this, but you always have to be careful about hidden "coupling" growing until it's out of control.



  5. Passing along our own context[ Go to top ]

    Thank you Ken,

    I will look into this "work area" thing.
    I have also been thinking about storing my context in a global hashtable or something similar. (I was actually planning on using ThreadLocal) Can I be absolutely sure that the entire request (within a single VM) is performed by a single thread? Otherwise I will not be able to use the thread id (or ThreadLocal).
  6. Passing along our own context[ Go to top ]

    So far this has worked for me in WebSphere. To be sure I guess you would have to talk to your app server vendor.

    I would imagine only one thread would be used to service one client request, no matter how many ejb's are involved.

  7. Passing along our own context[ Go to top ]

    Take a look at this documentation:

    http://www.redbooks.ibm.com/redbooks/SG246504.html

    Look for the "WorkArea" section. You don't have to buy the product, just "borrow" the ideas!

    They use JNDI, and also have a begin/end requirement. Just giving the doc a quick read, it is not clear to me what they are using as an identifier in JNDI.
  8. I am also very much interested in this.

    If anyone actually figures out what IBM uses as the JDNI key, please do let us know.

    My guess is the key involves some IBM-specific session ID that is passed from the webtier to the EJB tier so that both know about it and therefore can get to the right JNDI entry.

    If that is the case, I don't see how one can simulate the WorkArea concept without having the support from the app server vendor.

    Please, I would love to be proven wrong :)
    Greg
  9. Also,

    does anyone know whether a facility like "WorkArea" is available for Weblogic Server?

    Thanks
    Greg