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
EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053
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.