In the case where the cache limit is exceeded, you might see
a trace point similar to this:
BackgroundLru < EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit
Notice
the
Evicted = string. If you see this string, you are using either
Stateful Session Beans or Entity Beans configured for Option A or B caching.
Evicted objects mean you are not taking full advantage of the caching option
that you have chosen. Your first step is to try increasing the EJB Cache size.
If continued running of your application results in more evictions, it means
that the application is accessing or creating more new beans between EJB Cache
sweeps than the cache can hold, and
NOT re-using existing beans. At
this point, you might want to consider using Option C caching for your entity
beans, or checking your application to see if it is not removing Stateful
Session Beans after they are no longer needed.
Note: Entity beans configured
with Option C caching are only in the cache while in a transaction, and are
required to be held in the cache for the entire transaction. Therefore, they
are never evicted during a cache sweep, but are removed from the cache when
the transaction completes. In addition, if you are using only Stateless Session
Beans or Entity Beans with Option C caching (or both), then you might want
to increase your EJB Cache
cleanup interval to a larger number. The
cleanup interval can be set as described in
EJB cache settings.
Stateless Session Beans are
NOT in the EJB Cache, and since Entity
Beans using Option C caching are never evicted by the caching (LRU) strategy,
there is really no need to sweep very often. When using only Stateless Session
Beans or Option C caching, you should only see "Evicted = 0" in the trace
example shown above.