Stateful session bean destroying instance variables?

I'm trying to use a stateful session bean as some kind of login controller and to maintain the login id and access level across JSPs and HTMLs so that once logged in, all the JSPs can obtain the login name of the current user (String) and his access level (int).
I use the login.jsp to login and it successfully reports logging in with the correct access level retrieved from database. However, if I go to another JSP (testlogin.jsp), these 2 EJB instance variables are always destroyed and set to null and 0 when I access them again.
What am I missing that my stateful session bean is not saving these instance variables? Do I need to put them in some serializable value objects (create a help VO class?)
I suspected that on different JSP, I call the MemberControllerHome.create() method, it creates a new instance or something but if I don't use the create method how do I get a handle to MemberController at all?
MemberControllerBean.java
public class MemberControllerBean implements SessionBean {
     //initialize in ejbCreate.
     private MemberHome memberHome;
     SessionContext context;
     //Member currentLogin;
     //Current Login
     private String loginID;
     private int accessLevel;
     // Constructor
     public MemberControllerBean() {}
...some code in between...
public void login(String id, String password){
          try{
               Member member = null;
               member = memberHome.findByPrimaryKey(id);
               if(member.getMPassword().equals(password)){
                    this.loginID = member.getMID();
                    this.accessLevel = member.getMAccessLevel();
               else{
                    throw new EJBException("Login failed. Invalid member ID and/or password.");
          } catch (FinderException ex) {
               throw new EJBException("Login failed. Invalid member ID and/or password.");
     public void logout(){
          this.loginID = null;
          this.accessLevel = 4;
     public String getLoginID(){
          return this.loginID;
     public int getLoginAccessLevel(){
          return this.accessLevel;
login.jsp
String mID = request.getParameter("mID");
String mPassword = request.getParameter("mPassword");
out.println("20:" + mID + ":" + mPassword);
if(mID != null && mPassword != null){
     out.println("22:" + mID + ":" + mPassword);
     try{
          InitialContext ic = new InitialContext();
          MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
          MemberController mc = home.create();
          out.println("26:Logging in as " + mID + " with " + mPassword);
          mc.login(mID, mPassword);
          out.println("28:" + mc.getLoginID() + "logged in successfully at level " +
               mc.getLoginAccessLevel() + ".");
     } catch (NamingException ex) {
          out.println("java:comp/env/ejb/MemberController not found.");
     } catch (EJBException ex) {
          out.println(ex.getMessage());
     } catch (Exception ex) {
          out.println(ex.getMessage());
testlogin.jsp
<%
try{
     InitialContext ic = new InitialContext();
     MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
     MemberController mc = home.create();
     out.println("You are logged in as <b>" + mc.getLoginID() +
          "</b> at level <b>" + mc.getLoginAccessLevel() + "</b>.");
} catch (NamingException ex) {
     out.println("java:comp/env/ejb/MemberController not found.");
} catch (EJBException ex) {
     out.println(ex.getMessage());
} catch (Exception ex) {
     out.println(ex.getMessage());
%>

The key to the problem is that in testlogin.jsp a new stateful session bean is created. The new bean instance of course doesn't know the log-in information you stored in the old session bean. That is why the method returns null and 0 when called.
There are couple of ways to solve the issue. The easiest solution is to store the bean instance created in Login.jsp in the jsp's implicit HttpSession object. Because login.jsp and testlogin.jsp share the same session, the bean instance can be easily stored and retrieved.
Here is the code you need to have:
1. in login.jsp
session.setAttribute("MemberControllerBeanInstance", mc);
2. in testlogin.jsp
MemberController mc =
(MemberController) session.getAttribute("MemberControllerBeanInstance");
Hope it helps.

Similar Messages

  • How to get the Stateful Session bean instance in the second call

    Hi,
    I am new to EJBs. I have made a Stateful session bean on the first jsp page. In this page i am setting certain member variables of the EJB. Now in the second page i want to get these stored values in the EJB.
    In the second page do I...
    1. Store the instance of Remote Interface in the Session Context of the first JSP page and then in the second page get the Remote interface stored in its session context and call the business functions to get the values. If this is the case then what do u mean by Stateful Session beans??
    P.S.- This works fine.
    2. Try to get the Remote interface of that particular instance of the EJB(in which the values were stored) and call its business functions. IF this is possible. How do i do it??
    thanks in advance
    Anurag

    Hi,
    thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
    I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
    If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
    thanks in advance
    Anurag

  • Max number of instances for stateful session beans

    Hi,
    I am using OC4J 9.0.3 which is embedded in JDeveloper. I would like to set the maximum number of instances for stateful session beans. I know that the session-deployment section of the orion-ejb-jar.xml file has an attribute called max-instances, but it only works for stateless session beans. (at least it says so in the documentation and it did not work with my stateful session bean)
    Anyone knows how to do it?
    Thanks,
    Leonardo Penha

    Leonardo -- Stateful session beans do not come from a pool but are assigned 1 bean to 1 user. When the EJBs life ends the bean goes away. If what you are asking about is passivation configuraiton then that is different. We currently do not support passivation based on some count of SFSBs that exists inside the container but we will provide that capability in the next release of OC4J. (Note: When passivation occurs is mostly up to the vendors and it is not required by the J2EE 1.3 specification based on performance metrics. What is required is that when a SFSB is passivated it is done correctly and we do that.)
    Thanks -- Jeff

  • Context.lookup in a Servlet always returns the same Stateful Session Bean

    Hi,
    I am working on an application in which a Servlet should obtain one StateFul Session Bean per client. I read in EJB 3.0 in Action that to do so I should use a jndi lookup and save the result of the lookup in an HttpSession. This works fine for me when I have a single client.
    My issue is that when I have several clients, context.lookup returns the same SFSB for each client. This means that I end up having a single SFSB for the whole application. I've been browsing the web for a while now trying to find a solution but haven't had any luck yet.
    The code I use to obtain and save the SFSB is the following:
    HttpSession session = request.getSession(true);
    DFMServiceRemote service = (DFMServiceRemote) session.getAttribute("DFMService");
    if (null == service)
         service = (DFMServiceRemote) new InitialContext().lookup("DFMService");
         session.setAttribute("DFMService", service);
    }Using different browser, I end up with different HttpSession but a single SFSB. The only workaround I found is to create the context with environment variables or properties. It then returns different SFSBs for different HttpSession. The workaround code is as below:
    Hashtable<String, String> env = new Hashtable<String, String>();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
    env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
    env.put(Context.SECURITY_CREDENTIALS, "welcome");
    env.put(Context.PROVIDER_URL, "ormi://localhost:23791/DriverFatigue");
    service = (DFMServiceRemote) new InitialContext(env).lookup("DFMService");My question is the following. How can I get a different instance of an SFSB every time I execute context.lookup without specifying properties.
    Thanks in advance for any help,
    Matthieu Siggen

    I just did something similar in another project using JBoss instead of oc4j and didn't have any problem. I expect I missed a configuration file in oc4j or there is a conflict somewhere.

  • How to track the stateful Session Bean?

    Hi all,
    Am in a serious trouble. I have a message driven bean which will get initiated when some message gets dumped into the queue. I have got session bean which i use to process message which my message driven bean takes from the queue.
    My problem is, lets say there are 3 msgs in the queue. lets say the messages be "aaaa", "aaaa" and "bbbb".
    In this case, when i read the first message, i will create an instance of the session bean to process the message "aaaa". When i receive the second message still i create an instance to process the message "aaaa". When i get the 3rd message, i create an instance to process the message "bbbb".
    My problem in this is, i want to create only one instance of session bean for the message "aaaa".
    So once i create the instance for session bean for particular message, i need to store the object or something of the instance which i created along with the message. Please help me with what i can store with which i can reffer to the session bean again.
    Please see the sample code too.
    Thanks in advance,
    Ashly
    if(msg.equals("aaaa"))
    First n;
    Object obj = ctx.lookup("ejb/First");
    FirstHome home = (FirstHome) PortableRemoteObject.narrow(obj, FirstHome.class);
    n = home.create(msg);
    }

    Hi,
    thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
    I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
    If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
    thanks in advance
    Anurag

  • Passivation of Connection Object in Stateful Session Bean

    Hi all,
    I am developing a Stateful session bean that has a Connection object as its instance variable. And this bean starts transaction that spans across multiple method calls and finally either commit or rollback.
    BeanClass
    UserTransaction utx;
    Connection conn;
    ejbCreate()
    allocateconnection();
    ejbRemove()
    closeconnection();
    ejbActivate()
    allocateconnection();
    ejbpassivate()
    closeconnection();
    StartTransaction()
    utx = getusertransaction();
    utx.begin();
    Method1()
    do something with database
    Method2()
    do something with database
    CommitTransaction()
    utx.commit();
    For example, the typical usage of this bean would be:
    bean.StartTransaction();
    bean.Method1();
    bean.Method2();
    bean.CommitTransaction();
    Here are my two questions:
    1. General Question: In order for a Connection object to join a Transaction, Do I have to create the connection after the transaction has started?
    2. If the answer to the above question is yes, then: I understand that when this bean get passivated, the UserTransaction instance object would be passivated. And since the connection object can't not be passivated, I have to recreate the connection object in ejbactivate() method, would newly created connection participate in the same Transaction that was being passivated and now activated?

    >
    Hi all,
    I am developing a Stateful session bean that has a
    Connection object as its instance variable. And this
    bean starts transaction that spans across multiple
    method calls and finally either commit or rollback.
    BeanClass
    UserTransaction utx;
    Connection conn;
    ejbCreate()
    allocateconnection();
    ejbRemove()
    closeconnection();
    ejbActivate()
    allocateconnection();
    ejbpassivate()
    closeconnection();
    StartTransaction()
    utx = getusertransaction();
    utx.begin();
    Method1()
    do something with database
    Method2()
    do something with database
    CommitTransaction()
    utx.commit();
    For example, the typical usage of this bean would be:
    bean.StartTransaction();
    bean.Method1();
    bean.Method2();
    bean.CommitTransaction();
    Here are my two questions:
    1. General Question: In order for a Connection object
    to join a Transaction, Do I have to create the
    connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
    2. If the answer to the above question is yes, then: I
    understand that when this bean get passivated, the
    UserTransaction instance object would be passivated.
    And since the connection object can't not be
    passivated, I have to recreate the connection object
    in ejbactivate() method, would newly created
    connection participate in the same Transaction that
    was being passivated and now activated?
    The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work.

  • Stateful Session Bean accesed by two JSPs.

    Hi there,
    We are having quite an issue; we have an application that stores session
    state in an stateful session bean. And we have noticed some parts of the
    application create a situation where is possible that two frames -and so two
    jsp- access the session bean at the same time. And, of course, it´s going to
    be the same instance of the session bean..... what will be the behaviour in
    this case?. Will the requests be serialized, an exception will be thrown or
    the EJB will be destroyed?. Not very sure of what would happen. I suppose
    there could be some problems with this-. I would appreciate any help.
    Many thanks. Best regards.

    Hrm. EJB spec is quite clear on what will happen (RemoteException thrown) if
    the second client attempts to use Stateful Session bean which is already in
    use (and the bean will not be destroyed - container will simply throw an
    exception after failing to acquire a lock on the bean instance without waiting
    (allow-concurrent-calls option in WebLogic allows client call to wait to acquire
    lock - this was probably added as a convinience feature for applications which
    use frames)).
    So, normally your application has to ensure that no 2 clients are able to use
    the same stateful session bean concurrently, or use allow-concurrent-calls option,
    which will do that for you, but the application will become non portable.
    Dimitri
    PS: Thanks. Maine Coon cats are the best. Ours is a 22-pound giant ;-)
    Pinklon Thomas <[email protected]> wrote:
    Hi Dimitri,
    Thnaks a lot for the help:one thing that I do not know if it´s an issue is
    that calls come from different JSPs; the strategy I have seen in another Web
    application servers is trying to activate the EJB in the middle of another
    transaction... In this situation, the container cannot activate the EJB,
    roolback the transaction and destroys the EJB.... Would Weblogic feature
    avoid this?. I will investigate on my part....
    Many many thnaks. Nice cats.
    "Dimitri Rakitine" <[email protected]> wrote in message
    news:[email protected]...
    In 6.1 you can set allow-concurrent-calls to true in this situation:
    <!--
    The allow-concurrent-calls specifies whether a stateful session bean
    instance will allow concurrent method calls. The value of this
    element may be either "True" or "False". The default value is
    "False". When a stateful session bean instance is currently in a
    method call and another (concurrent) method call arrives on the
    server, the EJB specification requires that the server throw a
    RemoteException. By default, allow-concurrent-calls is false, and the
    EJB container will follow the EJB specification. When this value is
    set to true, the EJB container will block the concurrent method call
    and allow it to proceed when the previous call has completed.
    Used in: stateful-session-descriptor
    -->
    Pinklon Thomas <[email protected]> wrote:
    Hi there,
    We are having quite an issue; we have an application that stores
    session
    state in an stateful session bean. And we have noticed some parts of the
    application create a situation where is possible that two frames -and sotwo
    jsp- access the session bean at the same time. And, of course, it´sgoing to
    be the same instance of the session bean..... what will be the behaviourin
    this case?. Will the requests be serialized, an exception will be thrownor
    the EJB will be destroyed?. Not very sure of what would happen. Isuppose
    there could be some problems with this-. I would appreciate any help.
    Many thanks. Best regards.--
    Dimitri

  • Stateful session bean and faces

    I have one stateful session bean(EJB) that manages business logic and conditional page flow. In the web part i have a bunch of JSP pages and each page has it's own JSF bean with data and "submit" methods. Each bean has to keep a reference to this stateful bean and it should be the same reference among all beans. Also i have to create and destroy this bean some way (I think i can use HttpSessionBindingListener).So, any suggestions how to do this? Also i'm searching for 'tips'n'tricks' or design pattern for JSF.
    anton

    why do you need to hold the same EJB reference in all your JSF beans?
    something is wrong with your design, you should take a closer look to see why you need this. a stateless bean does not hold client specific state and there is no difference between stateless bean instances, so your JSF beans do not have to point to the same EJB reference.

  • Cannot remove stateful session bean when transaction timed out

    The transaction timeout is set to 5 minutes. After several operations on the transactional
    stateful session bean(implements SessionSynchronization), the transaction timed out
    after 5 minutes and I got the IllegalStateException when calling another business
    method. After the transaction rolled back, weblogic.ejb20.locks.LockTimedOutException
    was thrown when attempting to remove the bean. It seems the lock on the bean was
    not released even though the transaction had been rolled back. Does anyone know how
    to remove the bean in this kind of situation?
    Here is the stacktrace:
    ####<Jun 11, 2002 2:39:35 PM PDT> <Notice> <EJB> <app1x.zaplet.cc> <server25044server>
    <ExecuteThread: '11' for queue: 'default'> <> <23168:7b09681c532dc7e3> <010015> <Error
    marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the
    transaction for rollback. xid=23168:7b09681c532dc7e3, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException:
    Transaction timed out after 299 seconds
    Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
    'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
    Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]>
    java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23168:7b09681c532dc7e3,
    status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
    timed out after 299 seconds
    Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
    since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
    'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
    Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]
         at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1486)
         at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
         at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
         at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
         at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:371)
         at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
         at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:169)
         at mypackage.MyBean_wbr3eg_EOImpl.addRecipients(MyBean_wbr3eg_EOImpl.java:450)
    ####<Jun 11, 2002 2:39:37 PM PDT> <Info> <EJB> <app1x.zaplet.cc> <server25044server>
    <ExecuteThread: '11' for queue: 'default'> <> <> <010049> <EJB Exception in method:
    remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
    with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
    or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
    Group for Queue: 'default'].>
    weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
    with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
    or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
    Group for Queue: 'default'].
         at weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:448)
         at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:258)
         at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:226)
         at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:216)
         at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:310)
         at weblogic.ejb20.manager.StatefulSessionManager.remove(StatefulSessionManager.java:754)
         at weblogic.ejb20.internal.StatefulEJBObject.remove(StatefulEJBObject.java:86)
         at mypackage.MyBean_wbr3eg_EOImpl.remove(MyBean_wbr3eg_EOImpl.java:7308)

    If a stateful session throws a RuntimeException (your rollback) the container destroys the instance of the bean and all
    associated state information is lost, as required by the EJB specification.
    If you want to maintain client state it is generally best to use HttpSession objects (if you have a web application)
    for short-lived, client-specific data and JPA entities or other database backed storage for long-lived data.

  • Stop passivation in stateful session bean

    hi
    How to stop the passivation in stateful session bean
    Regards
    Gajendran.G

    >
    Hi all,
    I am developing a Stateful session bean that has a
    Connection object as its instance variable. And this
    bean starts transaction that spans across multiple
    method calls and finally either commit or rollback.
    BeanClass
    UserTransaction utx;
    Connection conn;
    ejbCreate()
    allocateconnection();
    ejbRemove()
    closeconnection();
    ejbActivate()
    allocateconnection();
    ejbpassivate()
    closeconnection();
    StartTransaction()
    utx = getusertransaction();
    utx.begin();
    Method1()
    do something with database
    Method2()
    do something with database
    CommitTransaction()
    utx.commit();
    For example, the typical usage of this bean would be:
    bean.StartTransaction();
    bean.Method1();
    bean.Method2();
    bean.CommitTransaction();
    Here are my two questions:
    1. General Question: In order for a Connection object
    to join a Transaction, Do I have to create the
    connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
    2. If the answer to the above question is yes, then: I
    understand that when this bean get passivated, the
    UserTransaction instance object would be passivated.
    And since the connection object can't not be
    passivated, I have to recreate the connection object
    in ejbactivate() method, would newly created
    connection participate in the same Transaction that
    was being passivated and now activated?
    The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work.

  • Error While passivating Stateful session bean

     

    I also have same problem when WL passivating. However, the exception throwing from
    WL saying the "Ignoring exception raised while passivating".
    My question is will that exception lead to failure of passivating and evenually
    lead to memory leakage? I just thought that the memory is still in cache either
    removed or passivated, as a result more and more memory will be used up as more
    failure occurs.
    Frank
    Rob Woollen <[email protected]> wrote:
    It looks like you have a reference to a DB Connection as a member
    variable. This reference should be transient. You can re-acquire it
    in
    ejbActivate.
    -- Rob
    Hemant Arora wrote:
    Hi
    Can anybody please clarify the error that I'm getting while runningthe
    stateful session bean with weblogic
    I have instantiated 20 stateful session beans all using the DB connection
    but if the connection is unaailable I'm making the beans to wait.
    I'm not removeing the beans and again making the instance of 20 another
    beans
    The max beans in cache is 25.
    Thanks
    Hemant
    This is the output at the console of the weblogic
    ejbPassivate()
    Tue Jul 17 20:58:00 GMT+05:30 2001:<I> <EJB JAR deployment
    d:/weblogic/myserver/romanCount.jar> Ignoring exception raised while
    passivating:
    java.io.NotSerializableException:
    weblogic.jdbc20.rmi.internal.ConnectionImpl
    at
    java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
    at
    java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
    at
    java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1841)
    at
    java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
    at
    java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
    at
    java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
    at
    java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1841)
    at
    java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
    Coming Soon: Building J2EE Applications & BEA WebLogic Server
    by Michael Girdley, Rob Woollen, and Sandra Emerson
    http://learnweblogic.com

  • Accessing the same stateful session bean from multiple clients in a clustered environment

    I am trying to access the same stateful session bean from multiple
              clients. I also want this bean to have failover support so we want to
              deploy it in a cluster. The following description is how we have tried
              to solve this problem, but it does not seem to be working. Any
              insight would be greatly appreciated!
              I have set up a cluster of three servers. I deployed a stateful
              session bean with in memory replication across the cluster. A client
              obtains a reference to an instance of one of these beans to handle a
              request. Subsequent requests will have to use the same bean and could
              come from various clients. So after using the bean the first client
              stores the handle to the bean (actually the replica aware stub) to be
              used by other clients to be able to obtain the bean. When another
              client retrieves the handle gets the replica aware stub and makes a
              call to the bean the request seems to unpredictably go to any of the
              three servers rather than the primary server hosting that bean. If the
              call goes to the primary server everything seems to work fine the
              session data is available and it gets backed up on the secondary
              server. If it happens to go to the secondary server a bean that has
              the correct session data services the request but gives the error
              <Failed to update the secondary copy of a stateful session bean from
              home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
              to the primary server will not reflect changes made on the secondary
              and vice versa. If the request happens to go to the third server that
              is not hosting an instance of that bean then the client receives an
              error that the bean was not available. From my understanding I thought
              the replica aware stub would know which server is the primary host for
              that bean and send the request there.
              Thanks in advance,
              Justin
              

              If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
              do you?
              Except of course if you switch ejb containers. Oh well.
              Mike
              "FBenvadi" <[email protected]> wrote:
              >I've got the same problem.
              >I understand from you that concurrent access to a stateful session bean
              >is
              >not allowed but there is a
              >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
              >that
              >does exactly what I need.
              >What you mean 'you'll get a surprise when you go to production' ?
              >I need to understand becouse I can still change the design.
              >Thanks Francesco
              >[email protected]
              >
              >"Mike Reiche" <[email protected]> wrote in message
              >news:[email protected]...
              >>
              >> Get the fix immediately from BEA and test it. It would be a shame to
              >wait
              >until
              >> December only to get a fix - that doesn't work.
              >>
              >> As for stateful session bean use - just remember that concurrent access
              >to
              >a stateful
              >> session bean is not allowed. Things will work fine until you go to
              >production
              >> and encounter some real load - then you will get a surprise.
              >>
              >> Mike
              >>
              >> [email protected] (Justin Meyer) wrote:
              >> >I just heard back from WebLogic Tech Support and they have confirmed
              >> >that this is a bug. Here is their reply:
              >> >
              >> >There is some problem in failover of stateful session beans when its
              >> >run from a java client.However, it is fixed now.
              >> >
              >> >The fix will be in SP2 which will be out by december.
              >> >
              >> >
              >> >Mike,
              >> >Thanks for your reply. I do infact believe we are correctly using
              >a
              >> >stateful session bean however it may have been misleading from my
              >> >description of the problem. We are not accessing the bean
              >> >concurrently from 2 different clients. The second client will only
              >> >come into play if the first client fails. In this case we want to
              >be
              >> >able to reacquire the handle to our stateful session bean and call
              >it
              >> >from the secondary client.
              >> >
              >> >
              >> >Justin
              >> >
              >> >"Mike Reiche" <[email protected]> wrote in message
              >news:<[email protected]>...
              >> >> You should be using an entity bean, not a stateful session bean
              >for
              >> >this application.
              >> >>
              >> >> A stateful session bean is intended to be keep state (stateful)
              >for
              >> >the duration
              >> >> of a client's session (session).
              >> >>
              >> >> It is not meant to be shared by different clients - in fact, if
              >you
              >> >attempt to
              >> >> access the same stateful session bean concurrently - it will throw
              >> >an exception.
              >> >>
              >> >> We did your little trick (storing/retrieving handle) with a stateful
              >> >session bean
              >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
              >sfsb's
              >> >were not
              >> >> replicated as yours are.
              >> >>
              >> >> Mike
              >> >>
              >> >> [email protected] (Justin Meyer) wrote:
              >> >> >I am trying to access the same stateful session bean from multiple
              >> >> >clients. I also want this bean to have failover support so we want
              >> >to
              >> >> >deploy it in a cluster. The following description is how we have
              >tried
              >> >> >to solve this problem, but it does not seem to be working. Any
              >> >> >insight would be greatly appreciated!
              >> >> >
              >> >> >I have set up a cluster of three servers. I deployed a stateful
              >> >> >session bean with in memory replication across the cluster. A client
              >> >> >obtains a reference to an instance of one of these beans to handle
              >> >a
              >> >> >request. Subsequent requests will have to use the same bean and
              >could
              >> >> >come from various clients. So after using the bean the first client
              >> >> >stores the handle to the bean (actually the replica aware stub)
              >to
              >> >be
              >> >> >used by other clients to be able to obtain the bean. When another
              >> >> >client retrieves the handle gets the replica aware stub and makes
              >> >a
              >> >> >call to the bean the request seems to unpredictably go to any of
              >the
              >> >> >three servers rather than the primary server hosting that bean.
              >If
              >> >the
              >> >> >call goes to the primary server everything seems to work fine the
              >> >> >session data is available and it gets backed up on the secondary
              >> >> >server. If it happens to go to the secondary server a bean that
              >has
              >> >> >the correct session data services the request but gives the error
              >> >> ><Failed to update the secondary copy of a stateful session bean
              >from
              >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
              >> >> >to the primary server will not reflect changes made on the secondary
              >> >> >and vice versa. If the request happens to go to the third server
              >that
              >> >> >is not hosting an instance of that bean then the client receives
              >an
              >> >> >error that the bean was not available. From my understanding I
              >thought
              >> >> >the replica aware stub would know which server is the primary host
              >> >for
              >> >> >that bean and send the request there.
              >> >> >
              >> >> >Thanks in advance,
              >> >> >Justin
              >>
              >
              >
              

  • Error in updating secondary stateful session bean

              Hi all,
              I have set up a cluster of 2 managed servers with WebLogic 6.1. I have a
              stateful session bean and several stateless session beans. the stateful
              session bean keeps user info and limited cached objects, all are
              serializable. it seems working fine, even after killing any one of the
              servers, as long as one is alive. a java application client creates a
              stateful session bean first, then calls stateless session beans with the
              remote interface of the stateful bean as a method parameter. No problem
              when stateful session bean is created. However, each stateless bean method
              generates the following error message if I turn the debug on (level 64). No
              exception stack traces, and all methods execute successfully.
              <Error> <EJB> <Failed to update the secondary copy of a stateful session
              bean from home:clientsession>
              I wonder what causes the error, and why it tries to update the stateful
              session bean. in all stateless session beans, only read into the stateful
              bean.
              Thank you,
              Fujin
              

    This has been fixed in WLS 6.1 SP2.
              jagdip Talla wrote:
              > Hi Fujin,
              > please let me know, if u were able to solve the problem..
              >
              > hi guys,
              > appreciate if you could give me some clues
              > how to solve this problem ?
              >
              > i hv 2 WLS instances in a cluster,
              > when one server instance is shut down, i keep getting these errors ?
              > is it normal ?
              > <Feb 19, 2002 2:57:53 PM SGT> <Error> <EJB> <Failed to update the secondary copy of a stateful session bean from home:ejb/xyzrel1_2/xxxxHome>
              >
              > appreciate if u can let me know, if u could solve it..?
              >
              > thanks n regads
              > jagdip
              Rajesh Mirchandani
              Developer Relations Engineer
              BEA Support
              

  • EJB 3.0 Stateful session bean shared between Servlet's

    Hello
    I have a bit of a noob question regarding Stateful sessions beans.
    I am wanting to know if there is a way that I can share an instance of a session bean between multiple HttpServlet instances?
    I am sending XML messages from a mobile J2ME application, there will be several http POST's made from the mobile client to the server. I would like these multiple POST's to be passed from the handling servlet instance to the same uniquely identified single stateful session bean instance (i can then @Remove the stateful bean when I have finished my several requests).
    I would greatly appreciate any tips anyone could give me.

    If not, your only option is to maintain the
    association yourself by creating a unique id for
    each
    conversation and storing that id along with the SFSB
    reference in the ServletContext. Then you'll
    need to pass the id in along with each invocation to
    retrieve the appropriate SFSB reference.Thanks for your reply.
    Will I always be presented with the same ServletContext instance? Even if the time between requests might be many minutes? Where can I learn more about how to use the ServletContext?
    Thanks!

  • How do i get back my stateful session bean after it has been passivated

    hi ,
    How do i get back my stateful session bean after it has been passivated by container.
    i'm confused that is it possible or not .......give me answer
    i've one stateful sessionbean which i'm accessing throgh my normal java client . now what i'm doing is when i first time call a method it is running ......then i'm shutting down the server jboss .......it is calling my ejbPassivate() method ... at this particular time client program doesn't do anything.....
    now after i restart my server i'm again calling back that business method with that last object reference.......it gives me the exception given below.....
    java.rmi.NoSuchObjectException: no such object in table
    java.rmi.NoSuchObjectException: no such object in table
         at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source)
         at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
         at sun.rmi.server.UnicastRef.invoke(Unknown Source)
         at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
         at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118)
         at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
         at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
         at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
         at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
         at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
         at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
         at $Proxy1.makeNewAcc(Unknown Source)
         at client.GanJavaClient.main(GanJavaClient.java:46)so pls tell me that is it possible to get back that session besn or not

    Stateful session beans are not persisted across restart of the EJB server instance(s) hosting them. You can't treat a Session bean as one would an entity bean.
    Chuck

Maybe you are looking for