Ben yes of course,
people think that they should use everything in the EJB. Like it is a sacred cow and you can't take anything apart. Damn it, it was written to taken apart, it was written to be eaten... I swear.
And when you code EJB in aspects something we have been doing since Rickard came around here then you realize that using a cache object (that you can look by any name in a real cache) to store JDBC results you are really using
1- a cmp entity bean
2- a cached object under a string name'
so drop all pretenses and cleanly talk to the system, in AOP JBoss 4.0 and let the system know that you want cache (give me the name) and persistence for this given java object.
bottom line, heu ben just fucking do it
Since Mr. Fleury seemed to be high on something ;-) (in a positive sense) I'll try to be more down to earth.
If you want the maximum performance and entity beans as cache go with BMP (Bean managed persistence) You can specify the bean as read only (read the docs on how to do this) and left the ejbStore and ejbCreate methods unimplemented. ejbLoad could (IMHO should) be implemented in DAO (data access object) where you can write as optimized JDBC code as you like.
If the users don't input the primary key directly there's usually no reason for findByPrimaryKey to actually look anything from database. Of course the wanted bean will be there! So just return the given Id back to the container.
Now when the ejbFindByPrimary is invoked what happens is that if the bean with the requested id is not found from the cache the container 'creates' a bean and invokes ejbLoad on it. So it's basically the same thing that you would make a direct JDBC call 'yourself'
The next time the same id is requested you get the bean from the cache. This can be up to tens of times more faster depending on the complexity of your cached data (from how many tables it was constructed, number of joins, etc...)
Just implement a simple getMyCachedData() method in the bean and you have a very nice database cache!