Stateful session bean purpose?

Currently I am struggling with the purpose of stateful session beans. Any client program should be able to maintain the state itself. Why am I using a session bean for this and loading the server with something that is really not of much value?
Can anyone give me a good example of when I need a stateful session bean, or at least a good use for one?
Thanks!

The jsp can certainly save the info in the "session" object. But I can see how this would be easier.
I have come to believe that stateful session beans just allow you to commonize your web interfaces with your non-web interfaces by abstracting lots of functionality into the EJBs.

Similar Messages

  • SAME EJB 3.0 Stateful Session bean for different JSP sessions returned

    Forum,
    I have a strange problem utilizing stateful session beans. Please note, that I am using jdeveloper for the following:
    1) Here is a basic stateful session bean:
    @Stateful(name = "DemoClass")
    public class DemoClassBean implements DemoClass,
               DemoClassLocal, SessionSynchronization {
          public static int id=0;
          public DemoClassBean() {
          id++;
          public int getId() {
             return id;
          //... other methods
    }2) This bean is accessed from a JSP for testing purpose, I am copying only the script used in JSP:
    <%
       DemoClass bean = null;
       try {
          bean = (DemoClass) ((new javax.naming.InitialContext()).
                       lookup("DemoClass "));
          System.out.println("ID=" + bean.getId() );
          } catch (javax.naming.NamingException e) {
             // TODO
    %>If this page is addressed by different clients, from different browsers, the same bean is returned.
    Here is what I see in the logs:
    ID=1
    ID=1
    ID=1
    The same problem is being observed when this session bean is accessed from a JSF Backing bean.
    What could be wrong? Is this a bug in oc4j / jdeveloper (version 10.1.3.3.0)?
    Edited by: smw000000001 on Nov 17, 2008 10:52 AM

    Hi,
    The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
    think of binding the stateful session bean with HttpSession object.
    So that you will get a unique stateful session bean object.

  • Howto call the @Remove method of a stateful session bean after JSF page ...

    I use EJB3, JPA, JSF in my web application. There are 2 database tables: Teacher and Student. A teacher can have many (or none) students and a student can have at most 1 teacher.
    I have a JSF page to print the teacher info and all his students' info. I don't want to load the students' info eagerly because there's another JSF page I need to display the teacher info only. So I have a stateful session bean to retrieve the teacher info and all his students' info. The persistence context in that stateful session bean has the type of PersistenceContextType.EXTENDED. The reason I choose a stateful session bean and an extended persistence context is that I want to write something like this without facing the lazy initialization exception:
    <h:dataTable value="#{backingBean.teacher.students}" var="student">
        <h:outputText value="${student.name}"/>
    </h:dataTable>Because my session bean is stateful, I have a method with the @Remove annotation. This method is empty because I don't want to persist anything to the database.
    Now, my question is: How can I make the @Remove method of my stateful session bean be called automatically when my JSF page finishes being rendered?

    Philip Petersen wrote:
    I have a few questions concerning the EJB remove method.
    1) What is the purpose of calling the remove method on stateless session
    bean?There isn't one.
    >
    2) What action does the container take when this method is called?It checks that you were allowed to call remove (a security check) and then
    just returns.
    >
    3) What happens to the stateless session bean if you do not call the remove
    method?Nothing
    >
    4) Is it a good practice to call the remove method, or should the remove
    method be avoided in the case of stateless session beans?
    Personally, I never do it.
    -- Rob
    >
    >
    Thanks in advance for any insight that you may provide.
    Phil--
    AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
    by Michael Girdley, Rob Woollen, and Sandra Emerson
    http://learnWebLogic.com
    [att1.html]

  • 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
              

  • How create  EJB 2.1 Stateful Session Bean in a EJB 3.0 Session Bean

    Hi All,
    We have been developing on EJB 2.1. We are now adding a module on EJB 3.0.
    How can we "create" a stateful session bean with create method signature similar to create(String id)?
    We have tried
    // this is the remote interface
    @EJB AddressBean abean;
    But not working
    Any help will be appreciated.

    There is no explicit create() call for EJB 3.0 session beans. It doesn't really matter though
    since you can accomplish the same thing by defining your own business method to act
    as an initializer for whatever state you'd like. E.g.
    @Remote
    public interface FooInterface {
    public void initialize(String id);
    // ... other business methods
    @EJB FooInterface fooRef;
    fooRef.initialize("foo");
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • 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!

  • Creating multiple stateful session beans from a java client. (EJB 3.0)

    I'm having difficulties with the following:
    To access the ShoppingCartBean, I have to put the following annotation in my standalone java client:
    @EJB
    private static ShoppingCartRemote shoppingCartBean;
    The static must be there, thus only one ShoppingCartBean will exist within my java client. But as the ShoppingCartBean is a stateful session bean, I want to be able to get different beans of the same type.
    What is the correct way to do this in EJB 3.0?

    Great question. Because Home interfaces have been removed for the EJB 3.0 simplified
    API, stateful session bean creation happens as a side-effect of injection. However, the
    same is true of EJB 3.0 business interface lookups. The easiest way to create additional
    stateful session beans is to lookup the same dependency that was declared via your
    @EJB annotation.
    E.g.,
    // Assuming the declaring class is pkg1.ShoppingCartClient.java
    InitialContext ic = new InitialContext();
    ShoppingCartRemote scr1 = (ShoppingCartRemote)
    ic.lookup("java:comp/env/pkg1.ShoppingCartClient/shoppingCartBean");
    Note that the name relative to java:comp/env is the default associated with your
    @EJB annotation since the name() attribute wasn't used. Alternatively, you
    could have used :
    @EJB(name="scb") private static ShoppingCartRemote shoppingCartBean;
    InitialContext ic = new InitialContext();
    ShoppingCartRemote scr1 = (ShoppingCartRemote) ic.lookup("java:comp/env/scb");
    Yet another alternative is to declare the @EJB at the class-level. This just defines
    the dependency without any injection, which is fine if you want to create a bunch of
    them via lookup anyway.
    @EJB(name="scb", beanInterface=ShoppingCartRemote.class)
    public class .... {                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Stateful Session Bean Initialization (EJB 3.0)

    Hi all!
    In EJB 2.1 the initialization was with create (args) methods. NOw, how is it exploited? Create methods are no more there and there must be a way to send parameters to the stateful session bean when it is newly created...isn't it?
    Thank you!

    There is no pre-defined equivalent of a create method in EJB 3.0. If you want to initialize a
    stateful session bean, just define a business method that the client should use as an initialization
    method.

  • 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

  • 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.

  • Deploy Error when using Stateful Session Bean inside Webdynpro

    Hi,
    I'm trying to create a webdynpro project that uses a stateful session bean
    I have created DC's for a EJB Module project, Enterprise Application and Webdynpro component. Created the bean, built it, added it's package to the public part, added the EJB Module to the EAR project. Built the EAR project. Added the EJB Module project and Enterprise Application project as a used DC in the Webdynpro DC.
    In the Webdynpro DC I added com.sap.archive-packaging.default.update-descriptors=true in the build.properties file of the cfg directory. (using the navigator view) That resolved an error while building it.
    Deployed the Enterprise Application DC without problems.
    Tried to deploy the Webdynpro DC but I get the following error:
    Jun 16, 2008 9:40:46 AM /userOut/deploy (com.sap.ide.eclipse.sdm.threading.DeployThreadManager) [Thread[Deploy Thread,5,main]] WARNING:
    [012]Deployment finished with warning
    Settings
    SDM host : 10.64.36.74
    SDM port : 50018
    URL to deploy : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
    Result
    => deployed with warning : file:/C:/DOCUME~1/JESCHA~1/LOCALS~1/Temp/temp59822company.nl~projempactcmp.ear
    Finished with warnings: development component 'projempactcmp'/'company.nl'/'local'/'20080616094022':Caught exception during application startup from SAP J2EE Engine's deploy service:java.rmi.RemoteException: Error occurred while starting application company.nl/projempactcmp and wait. Reason: Clusterwide execption: server ID 6060950:<--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key com.sap.engine.services.deploy.container.DeploymentException: <--Localization failed: ResourceBundle='com.sap.engine.services.deploy.DeployResourceBundle', ID='Failed implicit start for company.nl/projempejb : Unknown state(5)', Arguments: []--> : Can't find resource for bundle java.util.PropertyResourceBundle, key Failed implicit start for company.nl/projempejb : Unknown state(5) (message ID: com.sap.sdm.serverext.servertype.inqmy.extern.EngineApplOnlineDeployerImpl.performAction(DeploymentActionTypes).REMEXC)
    Deployment exception : Got problems during deployment
    Does anyone know what this error means and how to resolve it. I searched the forum but only found errors that look like this relating to XI not to Webdynpro.......
    Thansk,
    Jeschael
    Edited by: J.V. Lebbink on Jun 17, 2008 6:52 AM

    Default is 30mts.
    This is done as a parameter in orion-ejb-jar.xml. Please look at the EJB Guide at http://otn.oracle.com/docs/products/ias/doc_library/903doc_otn/generic.903/a97677/dtdxml.htm#634197 for details
    regards
    Debu

  • Stateful Session Beans are not passivated / serialized when cache idle time

    Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
    Initial error on Sun Solaris:
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.rmi.CORBA.Util.copyObject(Util.java:314)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    The above error caused the server to use all available memory and required a reboot to proceed.
    Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
    The server.log indicates that the beans are timing out:
    [19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
    Trace statements inserted in ejbPassivate do not appear in the log.
    It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
    The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
    My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
    Any suggestions would be appreciated.

    Thanks Thorick.
    I am using NRU caching. WL 7.0 SP2.
    I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
    the default value for this is 600secs. So the ejbs should be removed after this
    time. Below is the
    weblogic-ejb-jar.xml that I am using.
    <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
    'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
    <!-- Generated XML! -->
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean>
    <ejb-name>Cart</ejb-name>
    <stateful-session-descriptor>
    <stateful-session-clustering>
    <home-is-clusterable>true</home-is-clusterable>
    <replication-type>InMemory</replication-type>
    </stateful-session-clustering>
    </stateful-session-descriptor>
    <transaction-descriptor>
         <trans-timeout-seconds>
              60
         </trans-timeout-seconds>
    </transaction-descriptor>
    <jndi-name>CartHome</jndi-name>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    "thorick" <[email protected]> wrote:
    >
    The idle-timeout-seconds property controls the timeout/removal behavior.
    which stateful session cache type are you using ? LRUCache or NRUCache

  • 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

  • Reentrant call to a stateful session bean

    Hi,
    I have a problem that seems to be a very common problem but I
    steel didn't find any solution for it.
    We have a jsp page that call to stateful session been, the
    problem occur when I click twice on any link/button then I get
    java.rmi.RemoteException: Illegal attempt to make a reentrant call to a stateful
    session bean from home:....
    I have tried to set the <allow-concurrent-calls> to true but it doesn't help,
    I am getting this exception no matter the value of this tag.
    I am using WL61 sp2 (the last version) , Does anybody find a solution for that,
    I don't want to use javascript in order to work around this problem.
    Thanks,

    I think this is a different error from concurrent access (when client's
    attempt to access the same bean concurrently WebLogic throws LockTimedOut error
    (or client blocks if allow-concurrent-calls is true)).
    This error probably means that your code attempetd to reenter bean in the same
    transaction - how do you invoke it and what is the stack trace?
    Haim Cohen <[email protected]> wrote:
    Hi,
    I have a problem that seems to be a very common problem but I
    steel didn't find any solution for it.
    We have a jsp page that call to stateful session been, the
    problem occur when I click twice on any link/button then I get
    java.rmi.RemoteException: Illegal attempt to make a reentrant call to a stateful
    session bean from home:....
    I have tried to set the <allow-concurrent-calls> to true but it doesn't help,
    I am getting this exception no matter the value of this tag.
    I am using WL61 sp2 (the last version) , Does anybody find a solution for that,
    I don't want to use javascript in order to work around this problem.
    Thanks, --
    Dimitri

Maybe you are looking for