Re: SFSB Question

[Alex Paransky]

Title: RE: SFSB Question

Passing a parameter in to stateless session bean will not help you, since the container is free to pool the beans as it wishes.  So when you are doing an Home.create() call the container is simply picking on of existing free session bean objects from it's pool.  If you did, somehow, managed to initialize the session with the id of the user, it would only confuse you later, since the same session would be used for a different user.

 

The best method I can think of, is explicitly passing the parameters to each call your client make on to the session bean.  You can package those parameters into a class called UserContext, for example, and make it easy to create the context:

 

class UserContext implements java.io.Serializable {

   String userId, sessionId, httpRequestId;

 

   public static UserContext getContext(HttpServletRequest request) {...}

}

 

There are other methods such as using entity beans without persistence, or using statefull session beans.  Both of these, however, will reduce the load balancing and fail over aspects of your system.  Do you really want to sacrifice these features for log4j?  Perhaps.  Perhaps Not.  You need to decide.

 

-AP_

 

 

 

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Friday, January 25, 2002 6:35 AM
To: [EMAIL PROTECTED]
Subject: Re: SFSB Question

The initialization parameter that's needed is a logging context object that allows us to use the NDC in log4j across VM's.  An example would be where we want the session id or user id associated with an HTTP request to be prepended to all log messages generated in the processing of that request.  Within a VM, the NDC in log4j handles this.  As soon as you make a remote call, however, you're executing in a different thread and the information in the NDC is lost.

-tb

-----Original Message-----
From:   Alex Paransky [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, January 24, 2002 5:35 PM
To:     Biske, Todd; [EMAIL PROTECTED]
Subject:        RE: SFSB Question

Stateless session beans imply that they cannot hold a state that is of any meaning to the client.  Thus it does not make sense for the client to try to pass in any kind of initialization parameter.  If you want to pass extra information into the session, that should be done via ejb-jar.xml descriptor in the session's environment.  If you describe why you need to do this, perhaps a better solution could be found.


State full sessions beans are expensive, and cannot be cached or re-used by the container.
 
-AP_

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Thursday, January 24, 2002 2:58 PM
To: [EMAIL PROTECTED]
Subject: SFSB Question



On the project I'm working on, we've got a situation where it would extremely valuable to be able to have parameterized ejbCreate() methods on our stateless session beans, but the spec doesn't allow for this (we could put them in, but they'd never get invoked). 

One alternative would be to use stateful session beans, which allow this type of functionality.  The client would still be using the session bean in a stateless manner, however, e.g. one method call and it's done.  Is anyone aware of the potential overhead implications of making all of the session beans stateful versus stateless?  If it matters, the beans would be deployed under WL 6.1.

The other alternative that we're currently heading down is to take the parameter we'd like to pass in to ejbCreate() and add it to all of the business methods defined in the remote/local interface. 

Thoughts?
-tb





***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************



***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************