You can probably use the read-ahead strategry where the container will load a list of columns you specify in the group along with your id in one query. The extra data is stored in a seprate cache and your entity bean will be populated with the cached data during ejbLoad.
1) It only works when talking about data from one entity. What if my query went across several entities / tables, retrieving some attributes from each? Can't use a ejbFinder. And because ejbSelect statements can only return one result per row, they don't work either.
2) this declarative approach at build time forces the read-ahead strategy on all users of the bean, whether their transactions require it or not. Making it impossible to allow optimal performance per transaction.
The problem is that ejb querying is an insufficient API. At the moment I really feel this is broken by design, and that another solution such as Hibernate has to be used.
Please point out why I'm wrong. I would love not to be forced to convert all the entity bean code we have developed over the past year to Hibernate.
And a third problem:
3) I have to find out how to do this in every app server. We are an ISV and want to remain app-server independent. Because this is another of those glaring omissions from the EJB 2.x spec, it is solved differently, if solved at all, in each app server.
You could use left-join read-ahead, see wiki.
The spec does not define loading strategy. So it's a vendor-specific thing.
This is the same answer as provided by HariV(?)
What about the questions I raised in response to that (1 and 2, disregard 3).
1) Read about left-join read-head.
2) no other way but define a finder for a use-case.
Thanks for the response.
1) looks like a good solution.
2) here's the problem with entity beans. I have to know all my business cases in advance, declare them in the descriptors, and provide a finder for each. Everything is completely entity-centric, instead of usage (transaction) centric.
I get the following problems:
1) I could end up with lots of finders with incredibly long names so that the client knows what they do. Complicate my API for everyone to look at just for corner-case transactions.
2) The developer, working on a particular piece of logic, has to go to the entity, add a new finder and rebuild. Poor productivity.
3) I must verify that I can do this with other application servers
4) If I find that it can be done, attempt to put automatic processes in place in my build system to build the config for each
All when I just wanted to say "select these 10 fields from these 2 joined entities" in one transaction.
I think JBoss generally provides very good solutions within the constraints of the entity bean paradigm. More and more however, I find that the paradigm is inflexible and bars portability.
That is in no way intended to be a rant at JBoss. I will continue to use, recommend and deploy it, and I always genuinely appreciate the prompt and accurate advice I get from key figures on these forums, something I can never get from other vendors.
But I think that as an ISV who must remain portable, I must look to another persistence solution.
That's why we recommend Hibernate/EJB3.