I don't think that simply finding the bean (i.e. findByPrimaryKey or otherwise) will enlist the entity in the cache. You must call some member method of that bean for this to happen (i.e. myEntity.getId()).
Let me explain my need and why I think something is weird there.
We create an entity X and this one has CMR link to other entity (i.e. foreign key). Before creation this entity, the session bean validates those CMR links (i.e. the Ids of those entity exists in the DB). So each time I create a new instance of X, I do:
After having created 10000 instances of X, JBoss still do a select * from thetable where id = anId. It's crazy. We have commit A, it should be in the cache.
How are you getting the FK ids? When you get your entity X, say through:
EntityLocal x = xHome.findByPrimaryKey(xId);
Do you then get your FKs through
? If so, I don't understand then. The CMR I am familiar with makes that unecessary, unpossible. The container will make sure that ID exists, correct?
CMRs would allow you to say
EntityYLocal y = x.getY();
EntityZLocal z = x.getZ();
Either way, I'd think if you were using x.getId2() and x.getId3() as above that would enlist X in the cache.
Let's say I want to create a Book. A book as a CMR link to an editor and to an author for instance. I receive the following XML
[... other non CMR links]
The session bean that parses this XML validates the fact the author and the editor exists (that way I prevent a create exception and can give an approrpiate response to the user). So what Id do is:
My problem is that if I create 10.000 books from Jonh smith edited by ABC, jboss will still do
select from author where id = 'John Smith';
select fropm editor where id ="ABC";
Is it normal knowing that those haven't changed and I am using commit option A? What should I do to avoid those lookups?
I see what you are saying. It's my understanding that regardless of the cache, a findByPrimaryKey() will always hit the database.
I think that the reason for this is that a findByPrimaryKey() will return a handle, but not necessarily load the object; that happens when a method is invoked upon that object.
If you wanted to do a test to see if you could populate the entity cache with the Author and Editor entities, just try invoking one of their CMP accessor methods. I think that would do it. However, I don't think that will help you in preventing db accesses in your entity findByPrimaryKey() methods.
I'd be interested in learning how to avoid this as well.
My understanding of this is the following:
In order for a Bean to be in the cache a method must have been called on the bean found. So just doing findByPrimaryKey is not enough to load the bean into cache.
Once you have done findByPrimaryKey and called a method on the resulting entity, subsequent calls to findByPrimaryKey will not go to the database, but return the entity from the cache (as long as its there).
I'm no expert, but it might help.
I think an entity is cached only when a getter is called.
Also, I am not sure if commit option A works with Instance Per Transaction. this combination was not allowed earlier but i havent used the recent releases of jboss so i dont know if it is possible now.