HttpSession vs. Stateful Session Bean ---- when State Session is large

I hope most of the people come across with this issue where to put the state
for the internet/intranet based applications when they are using
servlet/jsps calling session beans. Weblogic 4.5.1 does support httpsession
in-memory replication for the servlets but the stateful session beans are
not replicated in clustered environment. Plus with stateful bean u get
activation/passivation overhead too. So one tempts to use stateless session
beans and store state in httpsession?
Then what is the upper limit for the session state one can put in
HttpSession with the weblogic? Is there any way to configure it?
One way to overcome the httpsession size limitation is to use database for
storing state and just store some unique Ids for the session info in
httpSession. But then there will be overhead for database connection?(jdbc
connection pool can provide some help here). So what is the recommended way
for doing this provided few thousand concurrent clients with session size
say exceeding 4kb per client?
Thanks
Usmani

There are no special setting in sun-ejb-jar.xml regarding cache settings. The default settings from server.xml are used:
    <jdbc-connection-pool steady-pool-size="8" max-pool-size="32" max-wait-time-in-millis="60000" pool-resize-quantity="2" idle-timeout-in-seconds="300" is-isolation-level-guaranteed="false" is-connection-validation-required="false" connection-validation-method="auto-commit" fail-all-connections="false" datasource-classname="oracle.jdbc.pool.OracleDataSource" name="ebs">
      <property value="jdbc:oracle:thin:@myebsdbsserver:1521:ebsdevdb" name="url"/>
      <property value="ebs" name="user"/>
      <property value="ebs" name="password"/>
    </jdbc-connection-pool>
  <ejb-container steady-pool-size="32" pool-resize-quantity="16" max-pool-size="64" cache-resize-quantity="32" max-cache-size="512" pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600" removal-timeout-in-seconds="5400" victim-selection-policy="nru" commit-option="B" monitoring-enabled="true">
     </ejb-container>The Session Bean uses Container Managed Transaction. Is it possible in this case, that the bean isn't 'idle enough' in order to set into passivated?

Similar Messages

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

  • 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

  • Losing UserTransaction state in Stateful session bean

    I have a UserTransaction I wish to begin and commit in different methods of a Stateful session bean. I have 2 methods to test this on the session bean:
    public void beginTransaction()
    trans = context.getUserTransaction() ;
    trans.begin() ;
    public void commitTransaction()
    trans = context.getUserTransaction() ;
    trans.commit() ;
    If I call these methods from one Perform method in a Struts action all works fine. If I call the methods in different Struts actions (storing the session bean handle on the HTTPSession in the first for retrieval in the second) the second call fails with the following exception:
    java.lang.IllegalStateException: No active Transaction
    The state of the transaction on the second call is STATUS_NO_TRANSACTION. I am certain that I have lost no state on the session bean and that using handles gives me the correct bean since I have written some state to test this. Basically something seems to close the transaction between the end of the first Perform method and the beginning of the second (I am of course assuming this is a valid thing to do).
    My session bean descriptor has <transaction-type>Bean</transaction-type>, and I am using OC4J.
    If anyone can point out what it is I am doing wrong I would be grateful!
    James.

    Sorry, I have re-checked my code and I believe I found the problem.
    I was beginning my transaction inside ejbCreate() and trying to commit/rollback in another method. This works in JBoss 3.2 but does not work in either OC4J or WebLogic 7.
    If I begin my transaction in a business method and commit/rollback in another method, everything works fine. (It also seems to work fine in 9.0.3 this way).
    So I am not sure whether this is a bug in 9iAS/WLS, or a bug in JBoss, or something that is left "vague" in the J2EE spec. Unfortunately, examples on bean-managed transactions are thin on the ground generally (the usual advice being not to use them, which I definitely agree with!).
    If you believe that the behaviour I describe is a bug in 9iAS, I can send a simple EJB test case.
    Keith

  • Local Stateful Session Bean State Failover Cluster

              Hi,
              How are you doing? I have poured through the previous postings and still am unclear
              on the following: If we have a stateful session bean that is local is the state
              replicated in a cluster if we are using in-memory replication?
              What controls when the state is replicated? Transactions?
              What happens if the methods are not transacted? Is the state replication at the
              method level?
              Thank you so much,
              -Bart Simpson
              

    Hi Bart,
              I'm a bit unclear on it too. It's been asked before, but no definite answer
              has been provided.
              Peace,
              Cameron Purdy
              Tangosol, Inc.
              http://www.tangosol.com/coherence.jsp
              Tangosol Coherence: Clustered Replicated Cache for Weblogic
              "Bart Simpson" <[email protected]> wrote in message
              news:[email protected]..
              >
              > Hi,
              >
              > How are you doing? I have poured through the previous postings and still
              am unclear
              > on the following: If we have a stateful session bean that is local is the
              state
              > replicated in a cluster if we are using in-memory replication?
              >
              > What controls when the state is replicated? Transactions?
              >
              > What happens if the methods are not transacted? Is the state replication
              at the
              > method level?
              >
              > Thank you so much,
              > -Bart Simpson
              

  • What are the advantages stateful session beans takes over than HttpSession

    Hi
    We can use HttpSession to maintain the conversational state with the client.
    Then why we need to go for stateful session beans to maintain conversational state with the client.
    What are advantages we can have while using stateful session beans ratherthan HttpSession????.
    Regards
    Dhinesh kumar R

    I think we can use the magic word in the software development "seperation of concerns" ;-)
    HttpSession is in the Servlet/JSP tier and is mainly used in the presentation logic tier (UI, page flows, navigation etc..)
    where the stateful session bean's concern is to maintain a conversational state in a business logic tier.
    Through this seperation its possible, that the business tier's state is undependant from the HttpSession and you dont create a hardlink that could cause problems later. Imagine having a desktop client accessing your business logic etc. not every client needs to be a web client ;-)
    I hope that the answer helps you understanding the topic :-)
    Brgds,
    Nail

  • 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

  • Timout error when ADF Swing+BC deployed as Stateful Session Bean

    i deploy the AM as stateful session bean onto OC4J 10.1.3,and the Client access them by Java Web Start.
    the error message is
    Exception in thread "AWT-EventQueue-0" oracle.jbo.JboException: JBO-29000: Error resuming transaction; nested exception is:
         javax.transaction.InvalidTransactionException: Cannot resume transaction that has been rolledback, rollback cause=Timed out
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.processRemoteJboException(RootApplicationModuleImpl.java:435)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.doMessage(RootApplicationModuleImpl.java:333)
         at oracle.jbo.client.remote.ejb.EJBApplicationModuleImpl.doMessage(EJBApplicationModuleImpl.java:194)
         at oracle.jbo.client.remote.ApplicationModuleImpl.doMessage(ApplicationModuleImpl.java:6887)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1122)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1150)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest2(ApplicationModuleImpl.java:1219)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest(ApplicationModuleImpl.java:1187)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequestReceiveResponse(ApplicationModuleImpl.java:1234)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequestReceiveValues(ApplicationModuleImpl.java:1250)
         at oracle.jbo.client.remote.ApplicationModuleImpl.isRangeAt(ApplicationModuleImpl.java:3856)
         at oracle.jbo.client.remote.RowSetIteratorImpl.isRangeAtTop(RowSetIteratorImpl.java:1109)
         at oracle.jbo.client.remote.RowSetImpl.isRangeAtTop(RowSetImpl.java:861)
         at oracle.jbo.client.remote.ViewUsageImpl.isRangeAtTop(ViewUsageImpl.java:968)
         at oracle.jbo.uicli.binding.JUCtrlActionBinding.isOperationEnabled(JUCtrlActionBinding.java:409)
         at oracle.jbo.uicli.binding.JUCtrlActionBinding.isActionEnabled(JUCtrlActionBinding.java:247)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar._isEnabled(MyJUNavigationBar.java:1558)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar._updateButtonStates(MyJUNavigationBar.java:1506)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar$1.run(MyJUNavigationBar.java:1419)
         at java.awt.event.InvocationEvent.dispatch(Unknown Source)
         at java.awt.EventQueue.dispatchEvent(Unknown Source)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
         at java.awt.EventDispatchThread.run(Unknown Source)
    ## Detail 0 ##
    oracle.oc4j.rmi.OracleRemoteException: Error resuming transaction
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:202)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to /192.168.1.254
         at com.evermind.server.rmi.RMICall.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMICall.java:110)
         at com.evermind.server.rmi.RMICall.throwRecordedException(RMICall.java:128)
         at com.evermind.server.rmi.RMIClientConnection.obtainRemoteMethodResponse(RMIClientConnection.java:472)
         at com.evermind.server.rmi.RMIClientConnection.invokeMethod(RMIClientConnection.java:416)
         at com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:63)
         at com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:28)
         at com.evermind.server.ejb.StatefulSessionRemoteInvocationHandler.invoke(StatefulSessionRemoteInvocationHandler.java:31)
         at __Proxy6.doMessage(Unknown Source)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.invokeDoMessage(RootApplicationModuleImpl.java:485)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.doMessage(RootApplicationModuleImpl.java:325)
         at oracle.jbo.client.remote.ejb.EJBApplicationModuleImpl.doMessage(EJBApplicationModuleImpl.java:194)
         at oracle.jbo.client.remote.ApplicationModuleImpl.doMessage(ApplicationModuleImpl.java:6887)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1122)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1150)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest2(ApplicationModuleImpl.java:1219)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest(ApplicationModuleImpl.java:1187)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequestReceiveResponse(ApplicationModuleImpl.java:1234)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequestReceiveValues(ApplicationModuleImpl.java:1250)
         at oracle.jbo.client.remote.ApplicationModuleImpl.isRangeAt(ApplicationModuleImpl.java:3856)
         at oracle.jbo.client.remote.RowSetIteratorImpl.isRangeAtTop(RowSetIteratorImpl.java:1109)
         at oracle.jbo.client.remote.RowSetImpl.isRangeAtTop(RowSetImpl.java:861)
         at oracle.jbo.client.remote.ViewUsageImpl.isRangeAtTop(ViewUsageImpl.java:968)
         at oracle.jbo.uicli.binding.JUCtrlActionBinding.isOperationEnabled(JUCtrlActionBinding.java:409)
         at oracle.jbo.uicli.binding.JUCtrlActionBinding.isActionEnabled(JUCtrlActionBinding.java:247)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar._isEnabled(MyJUNavigationBar.java:1558)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar._updateButtonStates(MyJUNavigationBar.java:1506)
         at com.kunteng.fabric.jclientview.MyJUNavigationBar$1.run(MyJUNavigationBar.java:1419)
         at java.awt.event.InvocationEvent.dispatch(Unknown Source)
         at java.awt.EventQueue.dispatchEvent(Unknown Source)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
         at java.awt.EventDispatchThread.run(Unknown Source)
         Nested exception is:
    javax.transaction.InvalidTransactionException: Cannot resume transaction that has been rolledback, rollback cause=Timed out
         at com.evermind.server.ApplicationServerTransaction.resume(ApplicationServerTransaction.java:330)
         at com.evermind.server.ApplicationServerTransactionManager.resume(ApplicationServerTransactionManager.java:494)
         at com.evermind.server.ApplicationServer$2.resume(ApplicationServer.java:4559)
         at com.evermind.server.ejb.EJBTransactionManager.resume(EJBTransactionManager.java:209)
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:200)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to /192.168.1.254
         at oracle.oc4j.rmi.OracleRemoteException.receive(OracleRemoteException.java:123)
         at oracle.oc4j.rmi.RmiTransport.annotateException(RmiTransport.java:141)
         at com.evermind.server.rmi.RMIClientConnection.handleMethodInvocationResponse(RMIClientConnection.java:812)
         at com.evermind.server.rmi.RMIClientConnection.handleOrmiCommandResponse(RMIClientConnection.java:242)
         at com.evermind.server.rmi.RMIClientConnection.dispatchResponse(RMIClientConnection.java:197)
         at com.evermind.server.rmi.RMIClientConnection.processReceivedCommand(RMIClientConnection.java:179)
         at com.evermind.server.rmi.RMIConnection.handleCommand(RMIConnection.java:154)
         at com.evermind.server.rmi.RMIConnection.listenForOrmiCommands(RMIConnection.java:126)
         at com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:105)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Unknown Source)

    when i use BC4J Test tool to connect to the Stateful Session Bean ,meet the same error .The full error message is
    oracle.jbo.JboException: JBO-29000: Error resuming transaction; nested exception is:
         javax.transaction.InvalidTransactionException: Cannot resume transaction that has been rolledback, rollback cause=Timed out
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.processRemoteJboException(RootApplicationModuleImpl.java:435)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.doMessage(RootApplicationModuleImpl.java:333)
         at oracle.jbo.client.remote.ejb.EJBApplicationModuleImpl.doMessage(EJBApplicationModuleImpl.java:194)
         at oracle.jbo.client.remote.ApplicationModuleImpl.doMessage(ApplicationModuleImpl.java:6887)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1122)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1150)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest2(ApplicationModuleImpl.java:1219)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest(ApplicationModuleImpl.java:1187)
         at oracle.jbo.client.remote.ApplicationModuleImpl.createAndInitRow(ApplicationModuleImpl.java:3989)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createAndInitRow(RowSetIteratorImpl.java:1602)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createRow(RowSetIteratorImpl.java:1553)
         at oracle.jbo.client.remote.RowSetImpl.createRow(RowSetImpl.java:1022)
         at oracle.jbo.client.remote.ViewUsageImpl.createRow(ViewUsageImpl.java:1168)
         at oracle.jbo.jbotester.NavBar$rsInsert.doAction(NavBar.java:151)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
    ## Detail 0 ##
    oracle.oc4j.rmi.OracleRemoteException: Error resuming transaction
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:202)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to FUWUQI/192.168.1.254
         at com.evermind.server.rmi.RMICall.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMICall.java:110)
         at com.evermind.server.rmi.RMICall.throwRecordedException(RMICall.java:128)
         at com.evermind.server.rmi.RMIClientConnection.obtainRemoteMethodResponse(RMIClientConnection.java:472)
         at com.evermind.server.rmi.RMIClientConnection.invokeMethod(RMIClientConnection.java:416)
         at com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:63)
         at com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:28)
         at com.evermind.server.ejb.StatefulSessionRemoteInvocationHandler.invoke(StatefulSessionRemoteInvocationHandler.java:31)
         at __Proxy2.doMessage(Unknown Source)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.invokeDoMessage(RootApplicationModuleImpl.java:485)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.doMessage(RootApplicationModuleImpl.java:325)
         at oracle.jbo.client.remote.ejb.EJBApplicationModuleImpl.doMessage(EJBApplicationModuleImpl.java:194)
         at oracle.jbo.client.remote.ApplicationModuleImpl.doMessage(ApplicationModuleImpl.java:6887)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1122)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1150)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest2(ApplicationModuleImpl.java:1219)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest(ApplicationModuleImpl.java:1187)
         at oracle.jbo.client.remote.ApplicationModuleImpl.createAndInitRow(ApplicationModuleImpl.java:3989)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createAndInitRow(RowSetIteratorImpl.java:1602)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createRow(RowSetIteratorImpl.java:1553)
         at oracle.jbo.client.remote.RowSetImpl.createRow(RowSetImpl.java:1022)
         at oracle.jbo.client.remote.ViewUsageImpl.createRow(ViewUsageImpl.java:1168)
         at oracle.jbo.jbotester.NavBar$rsInsert.doAction(NavBar.java:151)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
         Nested exception is:
    javax.transaction.InvalidTransactionException: Cannot resume transaction that has been rolledback, rollback cause=Timed out
         at com.evermind.server.ApplicationServerTransaction.resume(ApplicationServerTransaction.java:330)
         at com.evermind.server.ApplicationServerTransactionManager.resume(ApplicationServerTransactionManager.java:494)
         at com.evermind.server.ApplicationServer$2.resume(ApplicationServer.java:4559)
         at com.evermind.server.ejb.EJBTransactionManager.resume(EJBTransactionManager.java:209)
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:200)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to FUWUQI/192.168.1.254
         at oracle.oc4j.rmi.OracleRemoteException.receive(OracleRemoteException.java:123)
         at oracle.oc4j.rmi.RmiTransport.annotateException(RmiTransport.java:141)
         at com.evermind.server.rmi.RMIClientConnection.handleMethodInvocationResponse(RMIClientConnection.java:812)
         at com.evermind.server.rmi.RMIClientConnection.handleOrmiCommandResponse(RMIClientConnection.java:242)
         at com.evermind.server.rmi.RMIClientConnection.dispatchResponse(RMIClientConnection.java:197)
         at com.evermind.server.rmi.RMIClientConnection.processReceivedCommand(RMIClientConnection.java:179)
         at com.evermind.server.rmi.RMIConnection.handleCommand(RMIConnection.java:154)
         at com.evermind.server.rmi.RMIConnection.listenForOrmiCommands(RMIConnection.java:126)
         at com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:105)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)
    ----- LEVEL 1: DETAIL 0 -----
    oracle.oc4j.rmi.OracleRemoteException: Error resuming transaction
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:202)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to FUWUQI/192.168.1.254
         at com.evermind.server.rmi.RMICall.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(RMICall.java:110)
         at com.evermind.server.rmi.RMICall.throwRecordedException(RMICall.java:128)
         at com.evermind.server.rmi.RMIClientConnection.obtainRemoteMethodResponse(RMIClientConnection.java:472)
         at com.evermind.server.rmi.RMIClientConnection.invokeMethod(RMIClientConnection.java:416)
         at com.evermind.server.rmi.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:63)
         at com.evermind.server.rmi.RecoverableRemoteInvocationHandler.invoke(RecoverableRemoteInvocationHandler.java:28)
         at com.evermind.server.ejb.StatefulSessionRemoteInvocationHandler.invoke(StatefulSessionRemoteInvocationHandler.java:31)
         at __Proxy2.doMessage(Unknown Source)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.invokeDoMessage(RootApplicationModuleImpl.java:485)
         at oracle.jbo.client.remote.ejb.RootApplicationModuleImpl.doMessage(RootApplicationModuleImpl.java:325)
         at oracle.jbo.client.remote.ejb.EJBApplicationModuleImpl.doMessage(EJBApplicationModuleImpl.java:194)
         at oracle.jbo.client.remote.ApplicationModuleImpl.doMessage(ApplicationModuleImpl.java:6887)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1122)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendServiceMessage(ApplicationModuleImpl.java:1150)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest2(ApplicationModuleImpl.java:1219)
         at oracle.jbo.client.remote.ApplicationModuleImpl.sendRequest(ApplicationModuleImpl.java:1187)
         at oracle.jbo.client.remote.ApplicationModuleImpl.createAndInitRow(ApplicationModuleImpl.java:3989)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createAndInitRow(RowSetIteratorImpl.java:1602)
         at oracle.jbo.client.remote.RowSetIteratorImpl.createRow(RowSetIteratorImpl.java:1553)
         at oracle.jbo.client.remote.RowSetImpl.createRow(RowSetImpl.java:1022)
         at oracle.jbo.client.remote.ViewUsageImpl.createRow(ViewUsageImpl.java:1168)
         at oracle.jbo.jbotester.NavBar$rsInsert.doAction(NavBar.java:151)
         at oracle.jbo.jbotester.AbstractJboAction.actionPerformed(AbstractJboAction.java:81)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
         at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
         at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
         at java.awt.Component.processMouseEvent(Component.java:5488)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
         at java.awt.Component.processEvent(Component.java:5253)
         at java.awt.Container.processEvent(Container.java:1966)
         at java.awt.Component.dispatchEventImpl(Component.java:3955)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
         Nested exception is:
    javax.transaction.InvalidTransactionException: Cannot resume transaction that has been rolledback, rollback cause=Timed out
         at com.evermind.server.ApplicationServerTransaction.resume(ApplicationServerTransaction.java:330)
         at com.evermind.server.ApplicationServerTransactionManager.resume(ApplicationServerTransactionManager.java:494)
         at com.evermind.server.ApplicationServer$2.resume(ApplicationServer.java:4559)
         at com.evermind.server.ejb.EJBTransactionManager.resume(EJBTransactionManager.java:209)
         at com.evermind.server.ejb.EJBTransactionManager.resumeRemote(EJBTransactionManager.java:200)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_transactionPostSuspend(StatefulSessionEJBObject.java:784)
         at com.evermind.server.ejb.interceptor.system.TxBeanManagedInterceptor.invoke(TxBeanManagedInterceptor.java:44)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
         at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:69)
         at com.evermind.server.ejb.StatefulSessionEJBObject.OC4J_invokeMethod(StatefulSessionEJBObject.java:840)
         at RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.doMessage(RemoteBaseManageAppModule_StatefulSessionBeanWrapper4.java:491)
         at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.evermind.server.rmi.RmiMethodCall.run(RmiMethodCall.java:53)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
         at java.lang.Thread.run(Thread.java:595)
    at connection to FUWUQI/192.168.1.254
         at oracle.oc4j.rmi.OracleRemoteException.receive(OracleRemoteException.java:123)
         at oracle.oc4j.rmi.RmiTransport.annotateException(RmiTransport.java:141)
         at com.evermind.server.rmi.RMIClientConnection.handleMethodInvocationResponse(RMIClientConnection.java:812)
         at com.evermind.server.rmi.RMIClientConnection.handleOrmiCommandResponse(RMIClientConnection.java:242)
         at com.evermind.server.rmi.RMIClientConnection.dispatchResponse(RMIClientConnection.java:197)
         at com.evermind.server.rmi.RMIClientConnection.processReceivedCommand(RMIClientConnection.java:179)
         at com.evermind.server.rmi.RMIConnection.handleCommand(RMIConnection.java:154)
         at com.evermind.server.rmi.RMIConnection.listenForOrmiCommands(RMIConnection.java:126)
         at com.evermind.server.rmi.RMIConnection.run(RMIConnection.java:105)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:814)
         at java.lang.Thread.run(Thread.java:595)

  • 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

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

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

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

  • Handling Transaction in Stateful Session Bean

    I wrote a public method like public void doTransaction()
    it will call 2 private method, like: methodA and methodB
    Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
    How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
    I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?

    Ok... Here it goes...
    You can do it in the following manner.
    As you said you have got 2 private methods doing d/b updates and these are called from a public method.
    Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
    Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
    Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
    The problem you are dealing with can typically very well handled by writing bean managed transaction.
    Hope this helps. If you need anymore clarity on my solution, please let me know.
    -amit

  • Stateful Session Bean accesed by two JSPs.

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

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

  • Stateful session bean destroying instance variables?

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

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

Maybe you are looking for

  • Table maintenance events

    Hello, Does anyone has a code example of table maintenance events? I have a custom table ( zitab ) , with a maintenance view in SM30. I would like to use the table maintenance events for some authorisation check before the data is displayed, then, de

  • Installing Windows XP on MacPro

    hi, i just bought a MacPro and i need to install windows xp on it. does anyone know how to do this? please let me know! thanks!

  • Flash player requirement - version number - aggregator

    I've recently, using Aggregator (Captivate 5), generated an aggregator swf as part of a training programme. Each swf brought into Aggregator had been (previously) published using a Publish Preference of Flash Player Version 9. There appears to be no

  • Importing video form iPhone 4?

    In the past with my iPhone 3Gs, I've been able to import video ujsing A3 (I think). On plugging in my iPhone 4, however, I see no way to import video. All the pictures are there on the import screen, but none of the movies. I have movies in A3 from m

  • I am trying to download purchased music onto my iPad but it says error every time, with every song. Why is this?

    I previously purchased songs from my iPhone but I now can't download it to my iPad mini. It keeps coming up with a message say error please retry