ejb caching not working -a bug??

[malian]

I have setup caching on my jboss, but it seems jboss is accessing the database everytime it gets an instance of ejb. It loads ejb only one, which is right, but it executes query on the database everyime I get an instance of an entity. That doesn't seem right because entity beans are supposed to contain an instance of a record and caching should allow jboss to reuse those instances instead of getting the values from database.

I set the commit-option to type A on standardjboss.xml and here is my cache setting:
<container-cache-conf>
<cache-policy>
org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy
</cache-policy>
<cache-policy-conf>
<min-capacity>50</min-capacity>
<max-capacity>1000000</max-capacity><overager-period>300</overager-period><max-bean-age>600</max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
<cache-load-factor>0.75</cache-load-factor>
</cache-policy-conf>
</container-cache-conf>

I changed commit option for all standard cmp entity bean container configuration. Please let me know if I am not understanding how caching works or it's a bug.

[adrian.brock]

What do you mean by
"executes query on the database everyime I get an instance of an entity"

Any finder except "findByPrimaryKey"
must go to the database.
The cache is a map of primary keys
to entity bean instances.

Regards,
Adrian

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[malian]

Thanks for replying. I didn't know that it only caches lookups for primary keys. It's really useless because most the time, the queries are not findByPrimaryKeys. Caching would be more useful if it queried instances in the memory instead of the database by doing a findall first and caching those beans. Is this a common approach for all ejb containers or just jboss?

[adrian.brock]

Hehe, got stung by the horrible jive cache
where the posts don't appear :-)

By default. the findByXXXX only retrieves the
primary keys. If the keys are already in cache
there is no extra database work.

I think there are plans in jboss4 to introduce
a more complicated cache/persistence engine.
This should be able to work out if a
query can be satisfied from cache.

In general this is a difficult problem.
e.g. an "order by" with some entities in cache
how do you know you have them all?
You'd end up building an in memory database
with the extra complication that some parts
aren't in memory (they're in the datastore).

If you are interested the findBy is implemented
by the CMPPersistenceManager and the
cache mostly by AbstractInstanceCache.
I guess a simple implementation would be to have
secondary indexes and a totally preloaded
cache.

You can setup hsqldb to be an in memory db,
but it has no transaction isolation and no
support for XA.

Regards,
Adrian

[malian]

Yes, I couldn't see my posts, and so I thought they weren't posted, that's why there are so many of the same messages... hahaha. Well, this time I hope it works the first time, but thanks for getting back with me. I would certainly like to preload some of my beans totally in cache. Could you be more specific about how I can do that? Those beans that I want to cache are very stable, they don't change often, and they do use orderby clause. You said that:"By default. the findByXXXX only retrieves the primary keys. If the keys are already in cache there is no extra database work." Does this mean that jboss looks in the cache first, then database? In my tests, every findby went to the database, even if I had ran the query right after another. Also, it would be great if you could explain in more detail how I can do what you said here: "I guess a simple implementation would be to have secondary indexes and a totally preloaded
cache."

Thank you very much!
Malia

[adrian.brock]

A simple way to load everything into cache
is to write an MBean that in its start() method
does findAll() an then access something in
each bean such as getID. Specify "onFind"
as the loading strategy will probably speed
this up.

findByPrimaryKey is served from cache,
every other finder goes to the db.

The thing I was talking about isn't implemented
in jboss. e.g.
findByName() has some index over the cache
by name.

Regards,
Adrian