Bean Passivation

Does anybody out there know how to turn off Stateful Bean passivation ? Any
help would be greatly appreciated.
Thanks
-Vivek

Have you investigated the settings about "beans in cache" etc.?
Also, make sure you ejbRemove session beans when you are done with them.
There's nothing worse than passivating stuff that no one even wants ;-)
Cameron Purdy
"Vivek Arya" <[email protected]> wrote in message
news:[email protected]..
Does anybody out there know how to turn off Stateful Bean passivation ?Any
help would be greatly appreciated.
Thanks
-Vivek

Similar Messages

Bean passivation not completed

Environment: WLS 6.1 SP2 on NT
Hi,
I am loading 50 entities (EJB 2.0 BMP) and playing with WLS configuration
to force the container to passivate them.
I set max-beans-in-cache to 100, idle-timeout-seconds to 10 seconds
and concurrency-strategy to Database.
In addtion, I set the passivation-strategy to transaction to make sure
the container will passivate the bean after every transaction.
I ran my test to list the details of my 50 objects. 50 local entities
are indeed created, but none are passivated.
I would have expected the container to passivate them after 10 seconds
given my idle-timeout-seconds value. My passivation-strategy being set
to transaction, I would have expected the container to passivate them
straight away anyway.
If I change max-beans-in-cache to 30, the container passivates 20 entities
(activation count 50, passivation count 20, idle beans count 20, beans in
use count 30)
If I run it again the values change as expected to
activation count 70 (50+20), passivation count 40 (20+20), idle beans count
20, beans in use count 30.
My questions are:
Is idle-timeout-seconds working ?
Is passivation-strategy working ?
Is the console displaying the right information?
Could someone tell me what is the best practice for passivation policy?
It is not normal that my 50 entities will sit there for the whole day even
if there are not used.
They should be passivated shouldn't they?
Cheers
Arnaud

Arnaud wrote:
Environment: WLS 6.1 SP2 on NT
Hi,
I am loading 50 entities (EJB 2.0 BMP) and playing with WLS configuration
to force the container to passivate them.
I set max-beans-in-cache to 100, idle-timeout-seconds to 10 seconds
and concurrency-strategy to Database.
In addtion, I set the passivation-strategy to transaction to make sure
the container will passivate the bean after every transaction.
Passivation-strategy was deprecated in 6.0. It doesn't do anything in
6.0 or later. Actually it never really worked correctly even in 5.1.
idle-timeout-seconds is not used for entity bean passivation. That
parameter is only used for session beans.
I ran my test to list the details of my 50 objects. 50 local entities
are indeed created, but none are passivated.
I would have expected the container to passivate them after 10 seconds
given my idle-timeout-seconds value. My passivation-strategy being set
to transaction, I would have expected the container to passivate them
straight away anyway.
If I change max-beans-in-cache to 30, the container passivates 20 entities
(activation count 50, passivation count 20, idle beans count 20, beans in
use count 30)Right
If I run it again the values change as expected to
activation count 70 (50+20), passivation count 40 (20+20), idle beans count
20, beans in use count 30.
My questions are:
Is idle-timeout-seconds working ?
Is passivation-strategy working ?See above
Is the console displaying the right information?
Could someone tell me what is the best practice for passivation policy?
It is not normal that my 50 entities will sit there for the whole day even
if there are not used.
They should be passivated shouldn't they?
It depends on your usage. The better solution is in 7.0 where you can
configure application caches that will hold many different types of
EJBs. They're better able to handle mixed EJB loads.
-- Rob
Cheers
Arnaud

Sateful session bean passivation

Hi,
We know that stateful session beans are passivated depending on certain parameters, which is based completely on the Application server.
The passivation of the Stateful Bean is specified by Spec.
But i wonder what happens to the EJBObject itself. Every Stateful session bean will have its corresponding EJBObject, what happens to this EJBObject when the Bean is passivated. Does the EJBObject dies or does it stay alive all the time...
Thanks in advance,
Vijay.

Basically EJBObject is the request interceptor it does not store any client specific information, If the SFSB is passivated then the corresponding EJBOject will be associated with some other SFSB instance.

Passivation in entity bean

statement
In an entity bean, passivation includes releasing resources as well as pushing back the data it is
holding to the underlying database prior to the passivation process.
Hi, when i read stateful session bean the author mentioned about passivation because the stateful bean must have to store the conversational states of many clients. so the bean pushes the data to the secondary stoarge (disk) for future use, if at some time any client needs them the bean could use those states.... thats passivation.
but in Entity bean, i see author also talking about passivation. though author did not explain much. the entity bean is already using a permanent storage . why they need any secondary storage which is meant for passivation ?
because here activation means grabbing data from underlying DB. How does passivation helps here ?

Just a guess - I have no idea about EJBs:
Could it be that passivaion in this case simply means "performing the stuff that's needed for an entity bean to be persistent"? An entity bean IIRC represents a persistent set of data, which means that at one point in time, the data must be stored (written to DB) to be accessible later. That'd mean "passivation" is simply a name for an entity bean's normal behavior.

The performance of Passivate and Activate!?

in the Stateful Session Bean, weblogic will PASSIVATE a bean instance into disk or db when the number of bean instances reach the max-beans-in-cache and ACTIVATE it when the client call it again.
but i wonder that the performance of the operation ,can it be very expensive and affect the responsive time very much? if the effect is depended on the persistence fields?
3ks a lot:)

I think there is some confusion about the Activation and Passoivation phenomenons. I have sincere doubts that bean activation and passivation has anything to do with max-beans-in-cache figure. It just affects the idle time, after which the server passivates the bean.
the main adea behind the bean passivation is to preserve the precious server memory during runtime. if the client is idle for certain time (which is totally decided by container), the state of bean instance is preserved and the bean instance is returned to the pool, where it can be used to serve some other clients. when the same client calls back again, the container randomly pickes up any available bean instance and initializes it's state with the previously saved state, so client feels that the same bean instance is serving him continuously.
now the how the container responds to the max-beans-in-cache figure. the container tries it's best to manage all the clients request with the "max-beans-in-cache" bean instances. if the total requests : max-beans-in-cache ratio is very high, the session time out becomes lesser and lesser and vice versa. but if container finds it's really hard to serve all the requests with the supplied max-beans-in-cache, then it can temporarily generate some more bean instances to improve efficiency and those extra bean instances would be killed (not passivated) if no longer needed.
this activation / passivation is to improve the performance and make it less expensive and not otherwise. Managing more no. of idle objects in the memory would be much more expensive than this operation.
hope this helps,

Could not passivate; failed to save state

Hi guys
I'm using ejb with a web application on jboss 4.0.5 with jdk 1.5 and i'm getting this exception:
11:53:50,390 WARN [AbstractInstanceCache] failed to passivate, id=f373o8gy-s
javax.ejb.EJBException: Could not passivate; failed to save state
        at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:423)
        at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:107)
        at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:209)
        at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:162)
        at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.run(LRUEnterpriseContextCachePolicy.java:450)
        at java.util.TimerThread.mainLoop(Timer.java:512)
        at java.util.TimerThread.run(Timer.java:462)
Caused by: java.io.NotSerializableException: java.lang.ThreadLocal
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
        at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:414)
        ... 6 moreMy code (Session bean statefull):
protected transient Log log;
private transient IdentitySession identitySession;
public void ejbPassivate() throws EJBException, RemoteException {
        log.debug("bean passivating... ");
        log = null;
        identitySession.close();
        identitySession = null;
    }the attributes are transient because i had read somewhere that like that i could avoid serialization problems. but they remain, i've tried with and without them and the output is the same.
IdentitySession is a non-serializable object and Log is a interface from commons logging also non-serializable.
can anyone help?
Message was edited by:
RicardoM

So those are the ONLY fields in your bean? Does the class declare a ThreadLocal field or is a
super-class that declares a ThreadLocal field? If not, it could be a JBoss bug. I'd recommend
posting on the JBoss forum.

JDO object id problem when working with an appserver

Hi,
I'm running into a problem when passing a JDO object id as an argument to a
bean. My client is finding a JDO object locally, then attempting to
instantiate a bean which wraps the JDO object. Since the JDO object is not
Serializable, I'm passing the object id to the bean constructor, so that the
bean can look up the object again, this time in the appserver, and wrap it,
without ever serializing the object.
I'm guessing that the JDOId class for the JDO object is generated on the fly
in the client, and therefore does not exist in the ClassLoader in the
appserver. Any ideas how I can fix this?
Thanks,
Eric
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException:
java.lang.ClassNotFoundException: test.TheTest$JDOId (no security manager:
RMI class loader disabled)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteC
all.java:245)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invokeHome(Unkno
wn Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:25
8)
at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182)
at $Proxy0.create(Unknown Source)
at test.TheTestRemote.<init>(Unknown Source)
at test.TheTest.getRemoteObject(TheTest.java:19)
at
com.hcm.tools.util.CollectionHelper.getFirst(CollectionHelper.java:23)
at
com.hcm.tools.jdo.JDOFactory.executeSingletonQuery(JDOFactory.java:234)
at test.Test.print(Test.java:22)
at test.Test.main(Test.java:11)

Hi David,
I'm trying to use JDO to completely replace Entity Beans. Of course, this
leaves me with an important question: how do you make the JDO object
available remotely? My answer is to wrap JDO objects with a stateful
session bean, and pass through method calls made on the bean to the JDO
object. Both the bean and the JDO object will implement some interface, so
you can use an object in a client without any knowledge as to whether it is
a bean or a JDO object. ( Important note: I can get away with this because
of another cool Solarmetric product, the session bean creator, which
enhances a simple java object into a session bean )
Now, once I have some interface implementation, maybe a local persistent
object, maybe a remote object, I will want to do something with it. There
are a couple considerations here. First, if I want to edit the object, I
need to make sure a transaction gets started. I do this by having my
session beans take care of starting and committing transactions. Since I
have written my own JDO Factory that takes care of synchronizing PM caches
across transactions, this has the effect of keeping all my caches in the
appserver up-to-date as well ( more on that if you're interested ). So, in
order to call a 'set' method, I need to ensure that the object I have is in
it's "remote" state, so-to-speak.
So I created an interface called RemotePersistentObject, which all these
other interfaces extend. It includes two methods, getRemoteObject (), and
getObjectId (). The reason for getObjectId (), instead of
getPersistentObject (), is that often times you don't want your JDO objects
to be Serializable, especially if you have JDO objects that you want to
guarantee remain unique ( say, no two Stock objects have the same ticker
symbol ). Besides, you want the remote object to represent the same
concept, and as soon as you serialize the persistent object, you have a copy
of the original JDO object that will no longer do nice things you'd like it
to do, like get updated when some transaction in a different thread modifies
a field.
So, to get around this serialization issue, I just pass the JDO object id to
the bean, and have the bean lookup and wrap the appropriate JDO object on
the server. I wrote a couple optional base classes that provide a lot of
the functionality for this, since it turns out that wrapping a
non-serializable JDO object is non-trivial. The problem there is that when
the bean passivates, it serializes the state of the session bean... oops.
So the base classes take care of keeping a transient reference to the actual
object, while keeping a non-transient ref to the object id. All attempts to
use the actual JDO object are filtered through a getObject () method, which,
if the transient ref has disappeared due to bean passivation, looks up the
object in a read-only PM again.
Hmmmm. Lots of stuff here. I'll stop here and answer any questions (
criticisms ) you may have.
-Eric
"David Ezzio" <[email protected]> wrote in message
news:[email protected]...
Eric,
Curious minds want to know: what are you up to here? I found this to
be a very interesting post, and I would like to know more about the
architecture you are using and its motivation if you can share it.
David Ezzio
Eric Lindauer wrote:
Hi,
I'm running into a problem when passing a JDO object id as an argument
to a
bean. My client is finding a JDO object locally, then attempting to
instantiate a bean which wraps the JDO object. Since the JDO object isnot
Serializable, I'm passing the object id to the bean constructor, so thatthe
bean can look up the object again, this time in the appserver, and wrapit,
without ever serializing the object.
I'm guessing that the JDOId class for the JDO object is generated on thefly
in the client, and therefore does not exist in the ClassLoader in the
appserver. Any ideas how I can fix this?
Thanks,
Eric
Exception in thread "main"java.lang.reflect.UndeclaredThrowableException:
java.lang.ClassNotFoundException: test.TheTest$JDOId (no securitymanager:
RMI class loader disabled)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteC
all.java:245)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invokeHome(Unkno
wn Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:25
8)
at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182)
at $Proxy0.create(Unknown Source)
at test.TheTestRemote.<init>(Unknown Source)
at test.TheTest.getRemoteObject(TheTest.java:19)
at
com.hcm.tools.util.CollectionHelper.getFirst(CollectionHelper.java:23)
at
com.hcm.tools.jdo.JDOFactory.executeSingletonQuery(JDOFactory.java:234)
at test.Test.print(Test.java:22)
at test.Test.main(Test.java:11)

Monitoring a running weblogic server

I am aware of the facilities provided by the weblogic console for monitoring
a running server but we would like to develop our own Java app that could
report statistics, take snapshots, etc. and also alert us when something we
consider worrying occurs.
I presume the console uses an API to get its information - is this API
published?
Does this apply to 5.x as well as 6.x?
We would like to monitor the following, if there is an API we can use does
it give us all this information:
heap utilisation
bean pool size and utilisation
bean passivation count
connection pool size and utilisation
TIA
Ed

I believe there's a serverinfo.zip in the alpha code section on the dev center as
well. It does some admin work with the 5.1 apis. That being said, officially
I don't believe we ever exposed these APIs, so YMMV.
-- Rob
Tom Barnes wrote:
Ed,
For 6.x, there is useful JMX sample code at the "Developer Center":
http://developer.bea.com:80/index.jsp.
Don't know about 5.1, but there might be something for that as well.
Tom
Ed Barrett wrote:
Rob,
Many thanks for your timely response.
Is you did not expose the API I presume it must be there. So maybe you
can't answer this but can anyone else point me at the classes, etc. I should
look at in 5.x to get the same sort of information.
Rob - please don't take this as being untoward or cheeky - just if someone
else has gone to the problem of finding this out and willing to share the
information I would appreciate it.
Cheers
Ed
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]..
In 6.x, the API is JMX, and it is exposed. I don't believe we exposed theAPI
in 5.1 or earlier. (It wasn't JMX.)
-- Rob
Ed Barrett wrote:
I am aware of the facilities provided by the weblogic console for
monitoring
a running server but we would like to develop our own Java app thatcould
report statistics, take snapshots, etc. and also alert us when somethingwe
consider worrying occurs.
I presume the console uses an API to get its information - is this API
published?
Does this apply to 5.x as well as 6.x?
We would like to monitor the following, if there is an API we can usedoes
it give us all this information:
heap utilisation
bean pool size and utilisation
bean passivation count
connection pool size and utilisation
TIA
Ed

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

Stress tests: Weblogic Passivation of entity beans

Dear all,
I'm doing stress tests that consist of hundreds of concurrent access calling the same entity beans.
I noticed a strange behaviour:
- we developed with weblogic 6.1 and everything is Ok.
- The production environment is in weblogic 7.1: the two most used entity Beans are never passivated. Each time such a bean is created, it is afterwards never reused and never passivated. This causes an undesirable full cache Exception.
I configured max-bean in cache to 2000 and timeout to 60 sec.
I'm sure it is a problem of WEBLOGIC 7.1 configuration but I do not have any idea on how to solve it.
Did someone have the same problem?
Regards.

BEA provides a fix that may solve some of the caching problems you mentioned. Name of the fix is: CR110440

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.

Passivation of stateless session bean

For a stateful session bean, we mention the system directory in the server xml where Server stores the state of passivated stateful session bean instances.
Please can any one tell, if more than one beans are to be passivated how does it happen for one server instance?

The exact manner in which stateful session beans are passivated is considered an implementation detail. It is completely transparent to the developer.
Some implementations use a file-system as a stateful session bean store, while others use a database or memory replication.
If you're asking about specific configuration details I recommend consulting your vendor's documentation.
--ken

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.

Max-beans-in-cache, transactions and passivation

WLS 6.1 sp4
database concurrency, oracle
I compute max-beans-in-cache as:
(max # fetched in a transaction) * (number of worker threads)
therefore if I think that a table with have at most 500 rows and the
server is configured with 20 worker threads I have 500 * 20 = 10000 as
my max-beans-in-cache.
In my test the table has 7 rows. In our load test I see the Beans In
Use Count go up to 9999 instances and then start passivation.
I have two questions:
1) What does 'Beans In Use Count' really mean
2) why is weblogic using much more memory than it should to store 7 unique entities?
thanks

See my comments below.
S
Chad Urso McDaniel <[email protected]> wrote:
>
I understand this, but WebLogic should either reuse objects in the
cache/pool or not cache them at all. There are cases where the objects in the cahce are used. For e.g. with entity
beans and Read-Only concurrancy, when cache-between-tx is set. However I noticed
this behavior for other cases too and therefore the caching is not all that intellegent.
Also the beans in the pool are reused.
The current situation results in
objects being allocated, referenced by the cache so they will never be
garbage collected, but the objects are never used again once their
transaction completes. This is very, very wasteful with memory.
In some cases as mentioned above.
S
"Sri" <[email protected]> writes:
Hi,
The reason for having so many entries is due to fact that there isno way WLS
would know there are only 7 rows in the db everytime an entity beanis created/modified/accessed.
For e.g., if you run a test where you do 'findAll' the first run wouldhave 7
beans and the next most likely (There is another parameter that youcould use
to control number of beans in the cache, idle-timeout-seconds. Thoughits not
clear from the doc how the entity beans are handled wrt this parameter,it might
passivate entity beans if this timeout occurs) 14 and so on. If thisis a overhead
for your system then reduce this number.
S
container start removing beans before Chad Urso McDaniel <[email protected]>
wrote:
WLS 6.1 sp4
database concurrency, oracle
I compute max-beans-in-cache as:
(max # fetched in a transaction) * (number of worker threads)
therefore if I think that a table with have at most 500 rows and the
server is configured with 20 worker threads I have 500 * 20 = 10000as
my max-beans-in-cache.
In my test the table has 7 rows. In our load test I see the BeansIn
Use Count go up to 9999 instances and then start passivation.
I have two questions:
1) What does 'Beans In Use Count' really mean
2) why is weblogic using much more memory than it should to store7 unique
entities?
thanks

Activation/ Passivation in a Sateteful Bean

I have one Stateful Bean in wich all fields are some of the following:
- primitive types
- Objects Serializable
- EJBHome Ref to an entiy bean
and when occurs one activation the following error is generated:
BEA-010024 17/Ago/2005 22H00m WEST Error EJB Error occurred during passivation: java.io.NotSerializableEx
ception: javax.naming.InitialContex
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054
     at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330
     at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302
     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052
     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278
     at weblogic.ejb20.swap.PassivationUtils.write(PassivationUtils.java:94
     at weblogic.ejb20.swap.DiskSwap.write(DiskSwap.java:214
     at weblogic.ejb20.manager.StatefulSessionManager.swapOut(StatefulSessionManager.java:1051
     at weblogic.ejb20.cache.NRUCache.moveInActiveToFree(NRUCache.java:550
     at weblogic.ejb20.cache.NRUCache.reclaimNodes(NRUCache.java:578
     at weblogic.ejb20.cache.NRUCache.getFreeNode(NRUCache.java:238
     at weblogic.ejb20.cache.NRUCache.put(NRUCache.java:318
     at weblogic.ejb20.manager.StatefulSessionManager.create(StatefulSessionManager.java:844
     at weblogic.ejb20.manager.StatefulSessionManager.remoteCreate(StatefulSessionManager.java:880
     at weblogic.ejb20.internal.StatefulEJBHome.create(StatefulEJBHome.java:133
     at com.tmn.portal.lojavirtual.carrinho.ejb.CarrinhoFacade_3wxcmw_HomeImpl.create(CarrinhoFacade_3wxcmw_HomeImpl.java:153
     at com.tmn.portal.lojavirtual.carrinho.ejb.CarrinhoFacade_3wxcmw_HomeImpl_WLSkel.invoke(Unknown Source
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477
     at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108
     at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415
     at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170
Why is this error generated?
I've already put all bean field with transient and the error still occurs.

I'd suggest debugging this by commenting out all the data fields in your bean and running something that will force passivation.
This should work. Then you can do a binary search by adding in half of your fields and seeing if passivation still fails etc.
This should help you narrow down the problem. If you're still having problems, please let us know.
-- Rob
WLS Blog http://dev2dev.bea.com/blog/rwoollen/

Bean Passivation

Similar Messages

Maybe you are looking for