EJB 2.0 STATEFUL SESSION BEANS -- ejbPassivate or ejbActivate is not called

Hi,
am using Oracle Jdevloper 9i. When i use Stateful Session beans the ejbPassivate or ejbActivated methods are not being called. What is the reason?

Hi Arun,
The decision of when to passivate a stateful session bean is up to a particular vendor's implementation. Typically each vendor will have some configuration that controls this decision, but it's certainly common for passivation to not take place for a given workload. Your best bet is to look at the Oracle documentation to see how the container makes its passivation decision.
--ken

Similar Messages

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

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

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

EJB 3.0 Stateful session bean shared between Servlet's

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

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

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.

Passivation of Connection Object in Stateful Session Bean

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

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

Stop passivation in stateful session bean

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

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

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 bean does not rollback TX

I am unable to figure out why my stateful session bean is unable to rollback transactions
when I throw an EJBException. My stateful session bean has an ejbCreate method
which calls 2 other creates on 2 entity beans. If one of the entity beans successfully
creates and the other throws a CreateException, i catch it and throw an EJBException.
The created entity bean should roll back but it doesnt. Can it be because I
am calling the beans from within the session bean's ejbCreate method?
All beans are set to transaction REQUIRED, using bea's TXDatasource, and running
WL 6.1 sp2 on windows 2000.
help!

Session bean create methods run in an unspecified transaction. So your two calls to the
entity bean are running in separate txs.
-- Rob
Rob Pak wrote:
I am unable to figure out why my stateful session bean is unable to rollback transactions
when I throw an EJBException. My stateful session bean has an ejbCreate method
which calls 2 other creates on 2 entity beans. If one of the entity beans successfully
creates and the other throws a CreateException, i catch it and throw an EJBException.
The created entity bean should roll back but it doesnt. Can it be because I
am calling the beans from within the session bean's ejbCreate method?
All beans are set to transaction REQUIRED, using bea's TXDatasource, and running
WL 6.1 sp2 on windows 2000.
help!--
AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnWebLogic.com
[att1.html]

Rolling back the transaction from stateful session bean

Hi,
How can I mark the transaction to be rolled back in a stateful session bean implementation?.
Should I call setRollbackOnly method or throw a RemoteException or throw an EJBException, etc.?
the configuration is :
OC4J 9.0.4
Stateful session bean
Related method has transaction attribute - "Required"
thanks & regards.
ps : I couldn't find a related topic even if this has been discussed before (too many topics). if so, excuses.
Erdem.

Tried using Bean managed transactions but with the same result. Given below is the sample code.
UserTransaction uts = null;
try {
uts = (UserTransaction)(ctx.getUserTransaction());
uts.begin();
Connection con = null;
con = getCountConnection();
PreparedStatement ps = con.prepareStatement(sqlselectUserId);
ps.executeUpdate();
PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
ps1.executeUpdate();
uts.commit();
catch(SQLException e) {
uts.rollback();

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

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

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

Stateful Session Bean Initialization (EJB 3.0)

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

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

How to intantiate Stateful session bean in EJB 3 ?

In EJB 2.x, to instantiate a Stateful Session bean the process was:
1. Lookup Home object
2. call create(args) method on Home, that in turn would call corresponding ejbCreate(args) on the bean implementation.
Now, in EJB 3, there is no concept of Home interaface, How can I instantiate a stateful session bean with some initialization parameters.
Thanks

Just the spec. NetBeans should only be providing the ability to add an ejbCreate method if the bean exposes a Local or Remote 2.x view.
Each lookup or injection of a stateful session bean results in a new bean instance. As long as you call your methods to populate the additional
state right after first acquiring the stateful session bean reference it will work.
--ken

[EJB] Stateful session bean--- strange error

hi guys,
here s my problem. i m trying to developp a stateful session bean with two ejbcreate method. one with parameters ( ejbcreate(int val)) and another one without (ejbcreate()).
The client can call ejbcreate without any pbs. everything s allright.
but when i try to get a remote access to the bean via a
MY_BEAN.create(5); then i got an error saying :
FAILED TO FIND METHOD FOR HASH ......
i dont understand cuz i checked my files many times and the two methods are implemented and declared in the home interface.
what should i do ?
please.
tery

Hi Tery,
You are in the wrong forum. This forum is for the Sun Java Studio Creator.
Cheers :-)!!!

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

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

EJB 2.0 STATEFUL SESSION BEANS -- ejbPassivate or ejbActivate is not called

Similar Messages

Maybe you are looking for