getCallerPrincipal().getName() and Local Interface

Discussions

EJB programming & troubleshooting: getCallerPrincipal().getName() and Local Interface

  1. Hi.
    On the serverside of our application, we have to Weblogic Servers (6.1) One WLS act as a client, and the other as a server. On both this servers, we run EJB's. On the 'server wls', we have two layers with EJB that we call facade and proxy. In the facade EJB, we use EJB Local interface to route method calls to the proxy. In the ejbCreate method in the facade, we do the lookup and create on the proxy, and hold the reference to the proxy as a private attribute in the facade bean. When the facade bean gets a call from a client, it routes the call to the proxy without doing something with the CallerPrincipal. In the proxy, we then extract the callerPrincipal by calling the getCallerPrincipal().getName() method.
    This seems to work when simple functional testing is done, but when we stress the server with 50 concurrent users, strange things happens with the user IDs (callerprincipal.getName). It's not certain that this is the problem...

    But can anyone tell me if the callerprincipal name should travel through the application with this design without beeing altered? I have some concern that the wrong context
    is beeing used in some cases, that causes the wrong userid to appear.
  2. Since your problem happens only in load test, so I suspect this may relate to synchronization between multiple threads. What is the relationship between the stateless Sessionbean and the facade client? Are you trying to use one SessionBean to serve all client requests?
  3. Thank you for your reply.
  4. The thing is that I didn't make the client my self.
    I shall look into the code.
    I heard that they cached the remote interface, and this would cause a problem ?
    In the client one should do the lookup for each method call to get a reference to the server ? But I't should work if they set the context for each method call? (if they set the userid for each method call).

    I'm not trying to use one SessionBean to serve all clients.
    In WLS6.1 you have a pool of sessionBeans that serves the clients.
  5. If the client side cache the remote interface, this may cause problem in load test because of synchronization between multiple threads. You're right that it should work if they set the context for each method call, but if the remote interface is cached, the client may try to use the SessionBean which has not finished the previous operation.
  6. We tried to do the create and even the lookup on the server-bean in each method in the 'client wls'. But the problem won't go away. We have turned on a lot of logging, and found out that the switch of users happens before the method call to my wls server. Its a complex application with 5 layers where we use CA's eTrust for Single Sign On. We now belive that the problem lies in Weblogic Server and/or the eTrust Server...