Stateful Session Exception

Hi All,
I've encountered a problem when integrating with the integrator.
I've written a session bean which calls the integrator API to start workflow or execute
task. The workflow will execute business operations defined in another stateful session
bean. However, sometimes (not all cases) I encountered the execption as stated in
the attachment and my operation fails to complete. Does anyone here know how to solve
this problem? Thanks.
Weblogic version is 6.0
Weblogic integration version is 2.0
Fred
[workflow.txt]

Thanks,
V
"Dimitri I. Rakitine" <[email protected]> wrote:
Yup, this is exactly what is supposed to happen. RemoteException isA system
exception
and it is container's responsibility to, among other things, discard the
bean instance.
If you want different behaviour then throw a checked application exception
(one which
subclasses java.lang.Exception and not RuntimeException or RemoteException).
Venki <[email protected]> wrote:
Hi,
Our statefull session bean gets deleted, whenever it throws Remoteexception.
Actually the internal exception is caught and the method throws' RemoteException.
After the exception the bean cannot be accessed from it's remote interface.All we
get is the error saying the bean is removed or deleted. Is this a knownbehavior.
All help appreciated
Thanks,
Venki
Exception :
     = ===================================
     = ======= Reason ===================
     = ===================================
     java.rmi.NoSuchObjectException: Bean has been deleted.
     Start server side stack trace:
     java.rmi.NoSuchObjectException: Bean has been deleted.
     at weblogic.ejb20.swap.DiskSwap.read(DiskSwap.java:155)
     at weblogic.ejb20.manager.StatefulSessionManager.getBean(StatefulSession
     Manager.java:242)
     at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessi
     onManager.java:313)
     at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:11
     7)
     at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject
     .java:170)--
Dimitri

Similar Messages

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)

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

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


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

Error in updating secondary stateful session bean

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


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

(ejb 3.0) stateful session facade?

Hello,
(1) Would you consider stateful session facade (whose client is a servlet) a bad design?
(2) How to have a stateful session facade referenced in a servlet? I am using Sun Application Server Platform Edition 9.0 and trying to make an injection:
@EJB(name="ejb/KOGSessionFacade")
protected KOGSessionFacade sessionFacade;
but then I get this error in deploy-time: "A stateful session bean can not be injected into a servlet. Please refer to EJB 3.0 Persistence API Specification section #5.2 for further information."
Thanks.

Using a Stateful Session facade from a Servlet is not necessarily a bad design. In some cases, you may want to do some cleanup work on completion of a transaction. Stateful Session beans provide a convenient way (By implementing SessionSynchronization interface) to do this.
In the servlet programming model, Servlets are not designed to be single threaded. So if you inject a StatefulSessionBean (SFSB) references then multiple threads could be possibly be invoking the SFSB concurrently. In this case, the EJBContainer (as required by the specification), will throw a well defined exception.
What you may want to do is to place this SFSB reference into you Servlet session.

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

Deploy Error when using Stateful Session Bean inside Webdynpro

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

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

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

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

Thanks Thorick.
I am using NRU caching. WL 7.0 SP2.
I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
the default value for this is 600secs. So the ejbs should be removed after this
time. Below is the
weblogic-ejb-jar.xml that I am using.
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>

<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

Reentrant call to a stateful session bean

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

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

Stateful session Bean in Model not working

I made a sample application very very simple, and the weblogic server cant find the @stateful annotation on the class. is it there another possibility? here i post the error i get:
[Running application MyTest1 on Server Instance IntegratedWebLogicServer...]
[09:48:51 PM] ---- Deployment started. ----
[09:48:51 PM] Target platform is (Weblogic 10.3).
[09:48:52 PM] Retrieving existing application information
[09:48:52 PM] Running dependency analysis...
[09:48:52 PM] Deploying 3 profiles...
[09:48:53 PM] Wrote Web Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ViewWebApp.war
[09:48:53 PM] Wrote EJB Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ModelEJB.jar
[09:48:53 PM] Wrote Enterprise Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1
[09:48:53 PM] Deploying Application...
<03-jun-2010 21H48' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275594533727' for task '2'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..'
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
     Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
     at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
     at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     Truncated. see log file for complete stacktrace
>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'MyTest1'.>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
     Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
     at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
     at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     Truncated. see log file for complete stacktrace
>
#### Cannot run application MyTest1 due to error deploying to IntegratedWebLogicServer.
[09:48:54 PM] #### Deployment incomplete. ####
[09:48:54 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)
[Application MyTest1 stopped and undeployed from Server Instance IntegratedWebLogicServer]
and the very simple class with a Local and Remote interfaces at Model project in jDeveloper 11g (11.1.1.3)
package test.core;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateful;
@Stateful(name = "ControlSessionBean", mappedName = "MyTest1-Model-ControlSessionBean")
public class ControlSessionBean implements ControlSessionRemote,
ControlSessionLocal
private String username;
private String password;
public ControlSessionBean()
public List simple()
List <String> s = new ArrayList();
s.add(username);
s.add(password);
return s;
any suggestions why it is not working??
sincerely
Israel S Llorens

not working... i tried to make the stateful session bean Control.. and is still not working the error i get now is this one:
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275661769594' for task '9'. Error is: 'weblogic.application.ModuleException: Could not setup environment'
weblogic.application.ModuleException: Could not setup environment
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
     at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
     at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
     at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
     Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
     at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
     at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
     at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
     at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
     Truncated. see log file for complete stacktrace
>
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Could not setup environment
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
     at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
     at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
     at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
     Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
     at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
     at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
     at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
     at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
     at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
     Truncated. see log file for complete stacktrace
>
[04:29:35 PM] #### Deployment incomplete. ####
[04:29:35 PM] Remote deployment failed

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

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

Initialize a stateful session bean from another

Hi,
I am trying to create and initialize a stateful session bean from another stateful session bean. The code is as follows
This method belongs to DefaultSessionBean where it creates the AdminSessionBean based on few checks and returns it to the client.
    public AdminSession getAdminSession() throws UnknownException, WarningException {
        checkSessionUser("getAdminSession");
        if (isAdmin()) {
            AdminSession adminSession;
            try {
                final Context context = IToolsUtil.getInitialContext();
                adminSession = (AdminSession)context.lookup("AdminSession");
                System.out.println("Successfully created the adminsession bean");
            } catch (NamingException ne) {
                ne.printStackTrace();
                throw new UnknownException (new CatalogHelper("ITOOLS_100019", new Object[]{"Admin", ne.getMessage()}));
            System.out.println("adminsession will be returned");
            return adminSession;
        } else {
            throw new WarningException (new CatalogHelper("ITOOLS_000042", sessionUser.getUserhandle()));
    }Another method in DefaultSessionBean, creates its local interface and returns it.
    public DefaultSessionLocal getDefaultSessionLocal() {
        DefaultSessionLocal dsl = (DefaultSessionLocal)context.getBusinessObject(DefaultSessionLocal.class);
        System.out.println("local created.");
        return dsl;
    }Client call initialize method of the AdminSessionBean which is mentioned below:
    public void initialize(DefaultSession ds) throws WarningException, UnknownException {
        this.ds = ds.getDefaultSessionLocal();
        this.rfl = ReadFieldList.getInstance();
        this.fm = new FinderMethods();
    }The client code where it gets the adminSession and initializes is
   public static AdminSession getAdminSession(DefaultSession ds) throws ViewException {
        AdminSession as;
        try {
            as = ds.getAdminSession();
            System.out.println("got admin session");
        } catch (WarningException we) {
             we.printStackTrace();
            throw new ViewException(we.getCatalogHelper());
        } catch (UnknownException ue) {
            ue.printStackTrace();
            throw new ViewException(ue.getCatalogHelper());
        } catch (OracleRemoteException ore) {
            ore.printStackTrace();
            throw new ViewException(new CatalogHelper("ITOOLS_050003", ore.getMessage()));
        // Initialize Admin Session
        try {
            System.out.println("before getting it.");
            as.initialize(ds);
            System.out.println("adminsession is initialized");
        } catch (WarningException we) {
            as.remove();
            as = null;
            throw new ViewException(we.getCatalogHelper());
        } catch (UnknownException ue) {
            as.remove();
            as = null;
            throw new ViewException(ue.getCatalogHelper());
        } catch (OracleRemoteException ore) {
            as.remove();
            as = null;
            throw new ViewException(new CatalogHelper("ITOOLS_050003", ore.getMessage()));
        System.out.println("got admin session");
        return as;
    }Apart from this I am using OC4J 10.1.3.1 tool test my application.
When I am calling initialize method of the AdminSession I am getting the following error.
06/10/24 12:26:08 Entered
06/10/24 12:26:08 got default session
06/10/24 12:26:08 Successfully created the adminsession bean
06/10/24 12:26:08 adminsession will be returned
06/10/24 12:26:08 got admin session
06/10/24 12:26:08 before getting it.
2006-10-24 12:26:08.156 WARNING J2EE RMI-00009 Exception returned by remote server: {0}
06/10/24 12:26:08 com.itools.vs.view.exception.ViewException
06/10/24 12:26:08      at com.itools.vs.view.util.ViewUtil.getAdminSession(ViewUtil.java:71)
06/10/24 12:26:08      at com.itools.vs.view.backing.Admin.CreateUser.submit_action(CreateUser.java:182)
06/10/24 12:26:08      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
06/10/24 12:26:08      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
06/10/24 12:26:08      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
06/10/24 12:26:08      at java.lang.reflect.Method.invoke(Method.java:585)
06/10/24 12:26:08      at com.sun.faces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:146)
06/10/24 12:26:08      at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:92)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.AjaxActionComponent.broadcast(AjaxActionComponent.java:88)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.AjaxViewRoot.processEvents(AjaxViewRoot.java:274)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:250)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.AjaxViewRoot.processApplication(AjaxViewRoot.java:405)
06/10/24 12:26:08      at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:95)
06/10/24 12:26:08      at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
06/10/24 12:26:08      at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:110)
06/10/24 12:26:08      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:213)
06/10/24 12:26:08      at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:67)
06/10/24 12:26:08      at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:223)
06/10/24 12:26:08      at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621)
06/10/24 12:26:08      at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)
06/10/24 12:26:08      at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866)
06/10/24 12:26:08      at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448)
06/10/24 12:26:08      at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216)
06/10/24 12:26:08      at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:117)
06/10/24 12:26:08      at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:110)
06/10/24 12:26:08      at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
06/10/24 12:26:08      at oracle.oc4j.network.ServerSocketAcceptHandler.procClientSocket(ServerSocketAcceptHandler.java:239)
06/10/24 12:26:08      at oracle.oc4j.network.ServerSocketAcceptHandler.access$700(ServerSocketAcceptHandler.java:34)
06/10/24 12:26:08      at oracle.oc4j.network.ServerSocketAcceptHandler$AcceptHandlerHorse.run(ServerSocketAcceptHandler.java:880)
06/10/24 12:26:08      at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
06/10/24 12:26:08      at java.lang.Thread.run(Thread.java:595)
06/10/24 12:26:08 ITOOLS_050003: Failed to get Admin Session.
Exception is "Error marshalling objects, Not Serializable: java.io.NotSerializableException: DefaultSession_RemoteProxy_6nein01; nested exception is:
     java.io.NotSerializableException: DefaultSession_RemoteProxy_6nein01".
[b/

Your remote client passes a DefaultSession to AdminSession.initialize(..). This DefaultSession has to be a remote type. In your client, how does it get DefaultSession?
Did your client look up DefaultSession, and have it return a (sessionContext.getBusinessObject(DefaultSession.class))? If so, it should work.

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

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

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

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:

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 Exception

Similar Messages

Maybe you are looking for