3 Replies Latest reply on Oct 8, 2003 11:51 AM by aparaapara

Entity beans not being cached in same TX?

aparaapara Oct 4, 2003 6:53 AM

At one point in my code I noticed that I was executing findByPrimaryKey on an EJB a little too much. This resulted in a SELECT ... FROM .... WHERE ID=? type of query to be generated often. To fix the problem, I thought that executing a finder that would bring all those objects into memory (at least during the same TX) would "pre-cache" the objects and avoid a SELECT .. FROM .. WHERE ID = ? from being executed too many times. So I did that, [findByProfile] in the next trace, but I still see a lot of [findByPrimaryKey] being executed.

I verified that TX exists it's state is 0 (active) and it's the same TX when a do my "pre-cache" fetch and later when I am doing findByPrimaryKey calls.

Why is the "pre-cache" NOT caching my objects for the duration of the TX? (JBOSS 3.2.2RC3)

06:15:33,339 INFO [STDOUT] org.jboss.tm.usertx.client.ServerVMClientUserTransaction@c57f88, 0
06:15:33,347 INFO [STDOUT] org.jboss.tm.usertx.client.ServerVMClientUserTransaction@c57f88, 0
06:15:33,351 DEBUG [findByProfile] Executing SQL: SELECT t0_pv.id, t0_pv.componentid FROM picturevalue t0_pv, profilecomponent t3_pc, profile t1_pc_profile, component t2_pc_component WHERE ((t1_pc_profile.id=?) AND t2_pc_component.componentValueId = t0_pv.id) AND (t3_pc.profileid=t1_pc_profile.id AND t3_pc.componentid=t2_pc_component.id)
06:15:33,365 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,389 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,400 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,428 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,439 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,451 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?
06:15:33,470 DEBUG [findByPrimaryKey] Executing SQL: SELECT id, componentid FROM picturevalue WHERE id=?

Thanks.
-AP_

1. Re: Entity beans not being cached in same TX?

aparaapara Oct 6, 2003 3:15 PM (in response to aparaapara)

I guess I am not sure if caching should or shout not be occuring. If I obtain some entity bean via some fashion in a TX, and then in another function of the same TX call a findByPrimaryKey to find the same bean, should the second find execute or should the bean be retrieved from the cache?

Am I missing some configuration parameter that caches objects per transaction?

Thanks.
-AP_
Actions
2. Re: Entity beans not being cached in same TX?

ioparra Oct 6, 2003 4:19 PM (in response to aparaapara)

You present a very simple question:
Can any application server cache the results of a finder method?
AND
Can we treat a findByPrimaryKey as a special case?

I would figure that, during the same transaction, a findByPrimaryKey with the primary key could return the results of a previous query.

While I think it is possible, I recall that in 3.0.6, it was not being done. There may be some legit reason for this. I would figure it has to do with specify a read-lock option or some combination of isolation. I think that on informix, an isolation level of READ_COMMITTED creates an inherit read lock on each row during a SELECT. On Oracle, a read lock is only created during a SELECT ... FOR UPDATE call. Informix now supports this "for update" call(I think).

But because of that, can an Appserver assume that:
1)in the same transaction
2)during a findByPK

I don't think you can get around the initial finder call. Unfortunately, I can't think of a REAL reason why it can't be optimized... It is possible that the row can be removed, because of that, the finder is required. But how about Pessimistic/Option B/Row-Locking Entities at SERIALIZABLE isolation. That's pretty restrictive and should stop anyone from deleting a row. In that case, you SHOULD be able to cache the findByPK(a slight overkill for overall performance IMO).

I think that even doing a commit option A with cacheing will still force this initial finder... IDKFS.

-Ivan

I'm curious if there is a way around this initial SQL
Actions
3. Re: Entity beans not being cached in same TX?

aparaapara Oct 8, 2003 11:51 AM (in response to aparaapara)

My application .ear, is composed of two major .jar files. The model .jar file and the services .jar file. The services .jar file is calling onto the EJB entity objects in the model .jar file.

It seems that even if I configure certain model EJB entity objects as read-only, they are still being read from the database when services .jar is accessing model .jar. This does not appear to occur when model .jar is accesing objects inside of its self.

This might be related to what I am seeing with certain entity beans not being cached.

Have any one noticed different behaviour (as far as caching/optimization is concerned) between Session beans in jar A accessing entity beans in jar B in the same .ear file?

Thanks.
-AP_
Actions

Go to original post