Stateful session bean time out

How to specify a stateful session beans's time out value?
Thanks,
Jack

Bear in mind that setting a timeout for a stateful session bean will
typically have no more effect than setting a maximum number of beans. As
with garbage collection in Java, beans become eligible for passivation or
removal when their timeout expires and there are more beans than the
maximum, but they will only be removed or passivated when the server runs
low on memory.
Dave
"jack" <[email protected]> wrote in message
news:[email protected]..
>
How to specify a stateful session beans's time out value?
Thanks,
Jack

Similar Messages

  • 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

  • Lock Timed out exception in stateful Session Bean

    Hi All,
    We have a stateful session bean and put the reference of the bean in HttpSession
    and retrieve it from other JSP.
    While calling a method from bean, we are often getting the following exception.
    Any help please?
    weblogic.ejb.extensions.LockTimedOutException: Lock for primaryKey:1018581328443_46
    could not be acquired without waiting.
    at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:134)
    at weblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:81)
    at weblogic.ejb.internal.StatefulEJBCache.bind(StatefulEJBCache.java:447)
    at weblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObject.java:159)
    at weblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:487)
    at com.elink.jbe.savejobses.SaveJobSesBeanEOImpl.getJobHeaderData(SaveJobSesBeanEOImpl.java:1258)
    at jsp_servlet._jobentry._jbeenquirydefaults._jspService(_jbeenquirydefaults.java:243)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
    at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
    at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
    at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)

    Hi Arjuna,
    Thanks for your suggestions. But can you also help me how to make the session
    bean thread safe?
    Thanks in Advance
    Srinath
    "Arjuna Chala" <[email protected]> wrote:
    Looks like you have two threads accessing the bean at the same time.
    You
    need to make it thread safe. Also, store the handle of the session bean
    instead of the session bean itself in the session.
    By the way, session beans (handle or otherwise) are not meant to be stored
    in the HttpSession, and here is why:
    http://groups.google.com/groups?q=stateful+session+bean+httpsession&hl=en&se
    lm=3b72acb9%40newsgroups.bea.com&rnum=6
    "srinath" <[email protected]> wrote in message
    news:[email protected]...
    Hi All,
    We have a stateful session bean and put the reference of the bean inHttpSession
    and retrieve it from other JSP.
    While calling a method from bean, we are often getting the followingexception.
    Any help please?
    weblogic.ejb.extensions.LockTimedOutException: Lock forprimaryKey:1018581328443_46
    could not be acquired without waiting.
    atweblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:134)
    atweblogic.ejb.internal.LockManagerImpl.lock(LockManagerImpl.java:81)
    atweblogic.ejb.internal.StatefulEJBCache.bind(StatefulEJBCache.java:447)
    atweblogic.ejb.internal.StatefulEJBObject.getContextForInvoke(StatefulEJBObjec
    t.java:159)
    atweblogic.ejb.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:487)
    atcom.elink.jbe.savejobses.SaveJobSesBeanEOImpl.getJobHeaderData(SaveJobSesBea
    nEOImpl.java:1258)
    atjsp_servlet._jobentry._jbeenquirydefaults._jspService(_jbeenquirydefaults.ja
    va:243)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    atweblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
    :123)
    atweblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
    l.java:761)
    atweblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
    l.java:708)
    atweblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
    Manager.java:252)
    atweblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
    atweblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)

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

  • 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

  • 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

  • Best way to remove Stateful session beans

    Hi folks.
    I'm running Weblogic 6.1. I'm trying to find the best way of removing
    stateful session beans. I know to call EJBObject.remove() on the
    client side, but this will not always happen if the client crashes or
    times out. This is a java client application connection to weblogic,
    no servlets are involved.
    Is there a way to signal the appserver to remove all stateful session
    beans associated with a user when the User logs out? I would rather
    not remove them using a time out mechanism.
    thanks.
    rob.

    But in the documentation and also based on my experience I noticed that the
    timeout does not take effect till the max-beans-in-cache limit is reached.
    How do you handle that?
    "Thomas Christen" <[email protected]> wrote in message
    news:3e35795d$[email protected]..
    Hi,
    Is there a way to signal the appserver to remove all stateful session
    beans associated with a user when the User logs out? I would rather
    not remove them using a time out mechanism.Had the same problem and solved it the following way :
    - The client has thread polling its sessionbean at the server (every 30
    Sec.)
    - The session bean has a short timeout (2 Minutes)
    If the client fails, the timeout will catch it otherwise the client will
    gracefully call remove bevor exit.
    Regards
    Tomy

  • 1) Second thread call to stateful session bean.

    Hi Friend,
    I read your threads on otn and i compared your problem with us and i analysed that your application and my application is same, So Plese can you help me in some issues.
    Friend, Please help me in these issues, Thanks for this
    We have very big ADF Swing+BC Application and deployed as Stateful Session Bean. in my application there are 500 Application Modules,For each application module i created Stateful session beans and deployed it on OC4J Container but when working on deployed application then i am getting time out error after 15 min of working.
    1). I set that parameter that you mentioned i.e jbo.ejb.txntimeout = 86400,but still it is giving me same error.
    2). Second Issue is of ---ORA-01000: maximum open cursors exceeded
    For this issue i chaged the Database Parameter i.e OpenCurser=2000, but still it is giving me same error,
    is there any parameter on application module required to change so that this error will not come.
    3). When i close the form then application module is not releasing database connection.
    4). (oracle.oc4j.rmi.OracleRemoteException) Second thread call to stateful session bean
    This error is also coming when I am using deployed application for long time i.e more than 15 min for Heavy Transactions

    Hi Suyog,
    How r u?
    We all are fine.
    I alerady tried for the Max Curser Property but it is not helpfull.
    I think again i have to go for closing opened db RS and statements.
    Thanks
    Vijay

  • Transaction inside a stateful session bean

    I've a stateful session bean that represents a shopping cart.
    It has the following checkout method():
    <pre>
    /* em.getTransaction().begin(); */
    reasons.clear();
    for(CartEntry ce : entries){
    // get the book reference for the cart entry
    Book relbook = books.findById(ce.getBook().getId());
    if( ce.getQuantity()> relbook.getQuantity() ){
    reasons.add("Item not availabel in this quantity");
    // TODO: need to rollback
    /*em.getTransaction().rollback();*/
    throw new Exception();
    } else{
    // update book quantities
    relbook.setQuantity( relbook.getQuantity() - ce.getQuantity() );
    /*em.getTransaction().commit();*/
    // end of conversational state
    cancel();
    </pre>
    This method checks for the quantity of the items with respect to the quantity in the cart entries.
    How can I perform a transaction here?
    I'd like to rollback it before throwing the exception. And I'd like to commit it at the end,.
    If I use the entity manager to get the transaction, I get this error:
    Exception Description: Cannot use an EntityTransaction while using JTA.

    Its sad to see someone using EJB technology and then completely throw all benefits of it out of the window. I highly advise you to look into Container Managed Transactions; learn what they help you to do and then apply it. When you know how, it will put a smile on your face as you'll see the transaction management stuff disappear before your eyes.
    , from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???Concurrency is a hard problem with no clearly defined answers to it other than "you need to design the code to guard against concurrency problems". In this specific case, the database protects against this happening by applying a row lock or a table lock while the transaction is active and you are making modifications. For more information about that, you should consult the documentation relating to your specific DBMS.

  • When will Stateful Session Bean be removed?

    I develop a stateful session bean and deploy it in the oc4j server successfully.
    I write a java GUI Frame.
    This Frame call this stateful Session bean and get some data,
    and hold its remote interface reference as Frame's private member.
    Code like that:
    public class CargoFrame extends JFrame
    //private member
    private DataPager dataPager;
    I found that before i release CargoFrame, Stateful session bean will be removed.
    And System report session time out.
    And i want to know when stateful session bean will be removed,
    and how to set the session time?

    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

  • My weblogic 7 can not run stateful session bean??

    Hi,all
    I create a stateful session bean in jbuilder 7 and deploy it to weblogic 7,it
    successed.The Home interface have a method like this:
    public TestRemote create(int var) throws RemoteException, CreateException;
    But the client test bean call the create(int var) method throwing
    a exception :
    java.lang.IllegalArgumentException: wrong number of arguments
    Start server side stack trace:
    java.lang.IllegalArgumentException: wrong number of arguments
         at java.lang.reflect.Constructor.newInstance(Native Method)
         at weblogic.rmi.internal.OIDManager.makeActivatableServerReference(OIDManager.java:203)
         at weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:129)
         at weblogic.common.internal.RemoteObjectReplacer.getReplacement(RemoteObjectReplacer.java:265)
         at weblogic.common.internal.RemoteObjectReplacer.replaceObject(RemoteObjectReplacer.java:107)
         at weblogic.common.internal.ChunkedObjectOutputStream.replaceObject(ChunkedObjectOutputStream.java:53)
         at weblogic.common.internal.ChunkedObjectOutputStream$NestedObjectOutputStream.replaceObject(ChunkedObjectOutputStream.java:239)
         at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
         at weblogic.common.internal.ChunkedObjectOutputStream.writeObject(ChunkedObjectOutputStream.java:107)
         at weblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream.java:82)
         at com.berserk.ejb.Test_a6z4o8_HomeImpl_WLSkel.invoke(Unknown Source)
         at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:346)
         at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:300)
         at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:762)
         at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:295)
         at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
    End server side stack trace
    -- Failed: create(0)
         at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109)
         at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:127)
         at com.berserk.ejb.Test_a6z4o8_HomeImpl_WLStub.create(Unknown Source)
         at com.berserk.ejb.TestClient1.create(TestClient1.java:102)
         at com.berserk.ejb.TestClient1.main(TestClient1.java:199)
    -- Return value from create(0): null.
    Then I deploy it to the borland application server 4.5,it did work!!
    Somebody can help me ?thx

    Try throwing a CreateException in ejbCreate (int var).
    Jackie wrote:
    hi,Sabha:
    My source codes is like this.
    the home interface:
    import java.rmi.*;
    import javax.ejb.*;
    public interface TestHome extends EJBHome
    public TestRemote create(int var) throws RemoteException, CreateException;
    the remote interface :
    import java.rmi.*;
    import javax.ejb.*;
    * <p>Title: </p>
    * <p>Description: </p>
    * <p>Copyright: Copyright (c) 2002</p>
    * <p>Company: </p>
    * @author unascribed
    * @version 1.0
    public interface TestRemote extends EJBObject
    public void saycool() throws java.rmi.RemoteException;
    the stateful bean:
    import java.rmi.*;
    import javax.ejb.*;
    public class Test implements SessionBean
    private SessionContext sessionContext;
    private int m_var;
    public void ejbCreate(int var)
    this.m_var=var;
    public void ejbRemove()
    public void ejbActivate()
    public void ejbPassivate()
    public void setSessionContext(SessionContext sessionContext)
    this.sessionContext = sessionContext;
    public void saycool() throws java.rmi.RemoteException
    System.out.println("so cool");
    the client test class:
    import javax.naming.*;
    import java.util.Properties;
    import javax.rmi.PortableRemoteObject;
    * <p>Title: </p>
    * <p>Description: </p>
    * <p>Copyright: Copyright (c) 2002</p>
    * <p>Company: </p>
    * @author unascribed
    * @version 1.0
    public class TestClient1
    static final private String ERROR_NULL_REMOTE = "Remote interface reference
    is null. It must be created by calling one of the Home interface methods first.";
    static final private int MAX_OUTPUT_LINE_LENGTH = 100;
    private boolean logging = true;
    private TestHome testHome = null;
    private TestRemote testRemote = null;
    //Construct the EJB test client
    public TestClient1()
    long startTime = 0;
    if (logging)
    log("Initializing bean access.");
    startTime = System.currentTimeMillis();
    try
    //get naming context
    Context ctx = getInitialContext();
    //look up jndi name
    Object ref = ctx.lookup("TestRemote");
    //cast to Home interface
    testHome = (TestHome) PortableRemoteObject.narrow(ref, TestHome.class);
    if (logging)
    long endTime = System.currentTimeMillis();
    log("Succeeded initializing bean access.");
    log("Execution time: " + (endTime - startTime) + " ms.");
    catch(Exception e)
    if (logging)
    log("Failed initializing bean access.");
    e.printStackTrace();
    private Context getInitialContext() throws Exception
    String url = "t3://lettam:7001";
    String user = null;
    String password = null;
    Properties properties = null;
    try
    properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    properties.put(Context.PROVIDER_URL, url);
    if (user != null)
    properties.put(Context.SECURITY_PRINCIPAL, user);
    properties.put(Context.SECURITY_CREDENTIALS, password == null
    ? "" : password);
    return new InitialContext(properties);
    catch(Exception e)
    log("Unable to connect to WebLogic server at " + url);
    log("Please make sure that the server is running.");
    throw e;
    // Methods that use Home interface methods to generate a Remote interface
    reference
    public TestRemote create(int var)
    long startTime = 0;
    if (logging)
    log("Calling create(" + var + ")");
    startTime = System.currentTimeMillis();
    try
    testRemote = testHome.create(var);
    if (logging)
    long endTime = System.currentTimeMillis();
    log("Succeeded: create(" + var + ")");
    log("Execution time: " + (endTime - startTime) + " ms.");
    catch(Exception e)
    if (logging)
    log("Failed: create(" + var + ")");
    e.printStackTrace();
    if (logging)
    log("Return value from create(" + var + "): " + testRemote + ".");
    return testRemote;
    // Methods that use Remote interface methods to access data through the bean
    public void saycool()
    if (testRemote == null)
    System.out.println("Error in saycool(): " + ERROR_NULL_REMOTE);
    return ;
    long startTime = 0;
    if (logging)
    log("Calling saycool()");
    startTime = System.currentTimeMillis();
    try
    testRemote.saycool();
    if (logging)
    long endTime = System.currentTimeMillis();
    log("Succeeded: saycool()");
    log("Execution time: " + (endTime - startTime) + " ms.");
    catch(Exception e)
    if (logging)
    log("Failed: saycool()");
    e.printStackTrace();
    public void testRemoteCallsWithDefaultArguments()
    if (testRemote == null)
    System.out.println("Error in testRemoteCallsWithDefaultArguments():
    " + ERROR_NULL_REMOTE);
    return ;
    saycool();
    // Utility Methods
    private void log(String message)
    if (message == null)
    System.out.println("-- null");
    return ;
    if (message.length() > MAX_OUTPUT_LINE_LENGTH)
    System.out.println("-- " + message.substring(0, MAX_OUTPUT_LINE_LENGTH)
    + " ...");
    else
    System.out.println("-- " + message);
    //Main method
    public static void main(String[] args)
    TestClient1 client = new TestClient1();
    client.create(0);
    // Use the client object to call one of the Home interface wrappers
    // above, to create a Remote interface reference to the bean.
    // If the return value is of the Remote interface type, you can use it
    // to access the remote interface methods. You can also just use the
    // client object to call the Remote interface wrappers.
    Thank you for your help!!
    "Sabha" <[email protected]> wrote:
    Can you attach the sources of your ejb. Thanks.
    -Sabha
    "Jackie Lee" <[email protected]> wrote in message
    news:[email protected]...
    Hi,all
    I create a stateful session bean in jbuilder 7 and deploy it to weblogic7,it
    successed.The Home interface have a method like this:
    public TestRemote create(int var) throws RemoteException,CreateException;
    But the client test bean call the create(int var) method throwing
    a exception :
    java.lang.IllegalArgumentException: wrong number of arguments
    Start server side stack trace:
    java.lang.IllegalArgumentException: wrong number of arguments
    at java.lang.reflect.Constructor.newInstance(Native Method)
    atweblogic.rmi.internal.OIDManager.makeActivatableServerReference(OIDManager.j
    ava:203)
    at weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:129)
    atweblogic.common.internal.RemoteObjectReplacer.getReplacement(RemoteObjectRep
    lacer.java:265)
    atweblogic.common.internal.RemoteObjectReplacer.replaceObject(RemoteObjectRepl
    acer.java:107)
    atweblogic.common.internal.ChunkedObjectOutputStream.replaceObject(ChunkedObje
    ctOutputStream.java:53)
    atweblogic.common.internal.ChunkedObjectOutputStream$NestedObjectOutputStream.
    replaceObject(ChunkedObjectOutputStream.java:239)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
    atweblogic.common.internal.ChunkedObjectOutputStream.writeObject(ChunkedObject
    OutputStream.java:107)
    atweblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream.java:8
    2)
    at com.berserk.ejb.Test_a6z4o8_HomeImpl_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:346)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:300)
    atweblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManage
    r.java:762)
    atweblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:295)
    atweblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:3
    0)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
    End server side stack trace
    -- Failed: create(0)
    atweblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.
    java:109)
    at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:127)
    at com.berserk.ejb.Test_a6z4o8_HomeImpl_WLStub.create(Unknown Source)
    at com.berserk.ejb.TestClient1.create(TestClient1.java:102)
    at com.berserk.ejb.TestClient1.main(TestClient1.java:199)
    -- Return value from create(0): null.
    Then I deploy it to the borland application server 4.5,it did work!!
    Somebody can help me ?thx
    Rajesh Mirchandani
    Developer Relations Engineer
    BEA Support

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

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

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

  • 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

  • Spotlight does not find files with "_" (underscores), but only for certain file types

    Hey Folks, this is strange, maybe someone has an idea. I already searched the internet for a while, nothing found so far. I have a file "calc_mean.m" on my desktop. When I type "calc" in spotlight, it shows the file. But when I type "calc_" it sudden

  • Can't play the videos?

    I just bought the first episode of Lost, and now when i try to play it, it makes me authorize my computer again, and then it says an unknown error has occured (-208). And then it doesnt play my video, anybody know what the deal is? Edit: My laptop pl

  • Question Related to Source System of BI7 Technical Content

    Hi Experts,    I activated BI7 Technical contents using SPRO Transaction. Activation is successfull. My question is that I could now find two source systems for each activated Datasource of Technical Content(One BI self source system and another R3 s

  • Sending ringtones to Nokia Surge as picture messag...

    So, I just got the Surge without the data plan (for now). On my old phone, I was able to go to mobile17.com, make a ringtone and send it as a picture message and walla! - ringtone on my phone.  However, with the Surge it doesn't give me the option to

  • Mail Doesn't Warn if Subject: is empty

    If both the content of the mail body and the Subject header are empty, Mail opens a warning box to let yo u know. But if just the Subject is empty, mail doesn't warn you. Seems like it used to. Now, BOTH body and Subject need to be empty. I would be