Questions about entity bean caching/pooling

Question

We have a large J2ee app running on weblogic6.1 sp4. We are using entity beans
with cmp/cmr. We have about 200 EntityBeans and accessed quite heavily. We are
struggling with what is the right setting of max-beans-in-cache and idle-time-out.
The current max heap setting is 2GB. With the current setting (default setting
of max-beans-in-cache to 1000, with a few exceptions to take care of cachefullexceptions)
we run into extended gc happening after about 4 hours. The memory freed gradually
reduces with time and lurks around the 30% mark after about 4 hours of run at
the expected load. In relation to this we had the following questions
1. What does caching mean?
a. If a bean with primary key 100 exists in the cache, and the following
is done what is expected
i. findByPrimaryKey(100)
ii. findBySomeOtherKey(xyz)
which results in loading up bean with primary key 100
iii. cmr access to bean with
primary key 100
Is the instance in the cache reused at all between transactions?
If there is minimal reuse of the beans in cache, Is it fair to assume that caching
can only help loading of beans within a transaction. If this is the case, is there
any driver to increase the max-beans-in-cache other than to avoid CacheFullException?
In other words, is it wrong to say that max-beans-in-cache should be set to the
minimum value so as to avoid CacheFullExceptions.
2. Again what is the driver of setting idle-time-out to a value? ( We currently
have it at 30 secs) Partly the answer to this question would again go back to
what amount of reuse is done from cache? Is it right to say that it should be
set to a very low value? (Why is the default 10 min?)
3. Can you provide us any documentation that explains how all this works
in more detail, particularly in relevance to entity beans. We have already read
the documentation from weblogic as is. Anything to give more explicit detail?
Any tools that can be of use.
4. What is the right parameter (from among the things that weblogic console
throws up) to look at for optimizing?
Thanks in advance for your help
Cheers
Arun

Answer 1

The behaviour changes according to these descriptor settings: concurrency-strategy,
db-is-shared and include-updates.
1. If concurrency-strategy is Database, then the database is used to provide locking
and db-is-shared is ignored. A bean's ejbLoad() is called once per transaction,
and the 'cache' is really a per-transaction pool. A findByPrimaryKey() always
initially hits the db, but can use the cache if called again in the same txn (although
you'd simply just pass a reference around). A findByAnythingElse() always hits
the db.
2. If concurrency-strategy is ReadOnly then the cache is longer-term: ejbLoad()
is only called when the bean is activated; thereafter, the number of times ejbLoad()
is called is influenced by the setting of read-timeout-seconds. A findByPrimaryKey()
can use the cache. A findByAnythingElse() can't.
3. If concurrency-strategy is Exclusive then db-is-shared influences how many
times ejbLoad() is called. If db-is-shared is false (i.e. the container has exclusive
use of the underlying table), then the ejbLoad() behaviour is more like ReadOnly
(2. above), and the cache is longer-term. If db-is-shared is true, then the ejbLoad()
behaviour is like Database (1. above).
Exclusive concurrency reduces ejbLoads(), increases the effectiveness of the cache,
but can reduce app concurrency as only one instance of an entity bean can exist
inside the server, and access to it is serialised at the txn level.
You can't use db-is-shared = false in a cluster. So Exclusive mode is less useful.
That's when you think long and hard about Tangosol Coherence (http://www.tangosol.com)
4. If include-updates is true, then the cache is flushed to the db before every
non-findByPrimaryKey() finder call so the finder (which always hits the db) will
get the latest bean values. This overrides a true setting of delay-updates-until-end-of-tx.
The max-beans-in-cache setting refers to the maximum number of active beans (really
beans that have been returned by a finder in a txn that hasn't committed). This
wasn't checked in SP2 (we have an app that accidently loads 30,000 beans in a
txn with a max-beans-in-cache of 3,000. Slow, but it works, showing 3,000 active
beans, and 27,000 passivated ones...).
This setting is checked in SP5, but I don't know about SP4. So you do need to
size appropriately.
In summary:
- The cache isn't nearly as useful as you'd like. You get far more db activity
with entity beans than you'd like (too many ejbLoads()). This is disappointing.
- findByPrimaryKey() finders can use the cache. How long the cache is kept around
depends on concurrency-strategy.
- findByAnythingElse() finders always hit the db.
WebLogic 8 tidies all this up a bit with a cache-between-transactions setting
and optimistic locking. But I believe findByAnythingElse() finders still have
to hit the db - ejbql is never run against the cache, but is always converted
to SQL and run against the db.
Hope this is of some help - feel free to email me at simon-dot-spruzen-at-rbos-dot-com
(you get the idea!)
simon.