Hi, I'm seeing the above behaviour on tests, which I didn't expect, and wonder if anyone has any comments on it...
- Posted by: Gwyn Evans
- Posted on: March 18 2006 15:02 EST
Basically, I've got some data that very rarely changes, so configured a trivial CMP bean as ReadOnly to read it. I've also got a DAO implementation that used the same Oracle data pool but which uses a PreparedStatement to query the DB.
When I test from a servlet running in the same EAR as the CMP & DAO (so local connections), I find that when repeatedly requesting a set of 3 different records from the DB, the DAO implementation come in at around 8 time faster than the CMP implementation, even when the CMP beans are being served out of the cache, e.g of 1000 accesses, all but the initial 3 came from the cache...
It then occurred that threading might play a part, but even with 30 threads running the same requests in parallel, the DAO implementation took an average of ~9ms/request, while the CMP implementation took ~80ms/request.
The DAO is actually going to the Oracle DB, although it's trivial SQL - no joins or anything.
Any comments, anyone - Is this expected, as it seems counter-intuative to me...
Is this expected, as it seems counter-intuative to me...Well, it does sound counter-intuitive to me too.
We are using read only beans too and had ensured that the call to look them up does not go to the database - but never tested their performance against plane jdbc before!
The following might be worth checking if you have not done it already -
even when the CMP beans are being served out of the cache, e.g of 1000 accesses, all but the initial 3 came from the cache...
1. How are you sure they are being served out of the cache? Have you turned on jdbc logging? Have you ensured that a db call is not being made ?
You can try setting the weblogic environment variable to see whether a db call is being made : -Dweblogic.ejb20.cmp.rdbms.codegen.verbose=true -Dweblogic.ejb20.cmp.rdbms.codegen.debug=true
Alternatively try jdbc spy driver.
2. Are you making them readonly by setting the concurrency-strategy element to ReadOnly ? Have you tried the cache-between-transaction option? (http://dev2dev.bea.com/pub/a/2005/11/tuning-cmp-ejbs.html?page=2)
I will test our setup too and see how that looks against simple jdbc call. Will appreciate if you could post any of your finding here.
Forgot to add one more thing -
The read only model will work only if you are using findByPrimaryKey to lookup the bean. Any other finder call will go to the database (I think).
Sorry, was off on other project & vacation, so haven't had a chance to investigate in more detail. I was getting the cache hits from the Weblogic Console stats, which gave the Cache Hits/Accesses numbers, rather than tracing...
I was using concurrency-strategy as ReadOnly but not a findByPrimaryKey, rather a finder that mapped to "SELECT OBJECT(o) FROM ConfigRO AS o WHERE o.name = ?1" where name was unique/non-null but not the primary key.
It didn't occur to me that it might still be hitting the DB while at the same time recording a cache hit, which will be worth checking if I get another chance...