beans in use current count meaning? (re: CacheFullException)

[Alan Cheung]

hi all,

could someone explain to me what is the meaning of "beans in use current count"? does it mean the number of beans that are currently participating in a transaction? or does it mean the number of beans that are currently servicing requests?

we are currently investigating problems with CacheFullException, our max-beans-in-pools is set to a very high number (10000) but we are certain that under no circumstance would a single transaction be using more than 1000 beans at a time (and the CacheFullException happens when the server is under very light loading). I also checked the very well written document from bea on Investigating CacheFullException and we found no related problems.

Some backgrounds:

WLS: 8.1 SP3
EJB: CMP
Concurrency Strategy: Database
DB: Oracle

We use MDB to service all client requests and we use BMT (i.e. UserTransaction) to manage our transaction. Within a onMessage(), I could begin / commit a transaction many times depending on the use cases. Could this be a problem?

thanks in advance for your help,

vincent

[bill kemp]

Hi,

This is a bit complicated, but I'll take a stab at it.

"Beans in Use Current Count" is the number of beans:
1. Entity - ready or active, both of which are associated with a client
2. Stateful - idle or active, both of which are associated with a client
3. Stateless - busy

max-beans-in-free-pool doesn't affect whether or not you get a
CacheFullException. max-beans-in-cache could affect this. However, if you
are using BMT, which you can't use on an entity EJB, you may experience
CacheFullException if you have not commited or rolled-back the transactions
on beans that are in the cache. The container cannot passivate entity beans
or stateful session beans when they are in a transaction. If you are calling
entity beans or stateful session beans from your message driven bean in a
BMT transaction and you don't manage that transaction properly, those beans
may get 'stuck' in the cache and not be useable or able to be passivated.
This could cause the cache to fill and the container cannot trim it because
all of the beans in the cache are involved in a transaction. So, even if you
set max-beans-in-cache to some outrageously high number, you may just be
prolonging the period of time before you get a CacheFullException if you
have a bunch of beans that are orphaned in transactions.

BTW, BEA recommends that you don't set max-beans-in-free-pool. The default
value should be enough, but again, this is not related to the
CacheFullException.

Hope this helps.

Bill

Post by Alan Cheung
hi all,
could someone explain to me what is the meaning of "beans in use current

count"? does it mean the number of beans that are currently participating in
a transaction? or does it mean the number of beans that are currently
servicing requests?

Post by Alan Cheung
we are currently investigating problems with CacheFullException, our

max-beans-in-pools is set to a very high number (10000) but we are certain
that under no circumstance would a single transaction be using more than
1000 beans at a time (and the CacheFullException happens when the server is
under very light loading). I also checked the very well written document
from bea on Investigating CacheFullException and we found no related
problems.

Post by Alan Cheung
WLS: 8.1 SP3
EJB: CMP
Concurrency Strategy: Database
DB: Oracle
We use MDB to service all client requests and we use BMT (i.e.

UserTransaction) to manage our transaction. Within a onMessage(), I could
begin / commit a transaction many times depending on the use cases. Could
this be a problem?

Post by Alan Cheung
thanks in advance for your help,
vincent