Hi all,
I've been using EJBs for some time now and I feel that they have one major limitation that needs to be addressed in the specification.
I am referring to the ability of being able to operate on large numbers of EJB in a single transaction.
By the nature of EJBs, it is not possible to efficiently work on a large number of objects at once. This is because, for each object you wish to work on, the container must physically create a Java object, and invoke methods on it etc.
A practical example of this problem is the common business problem of creating reports.
In a report, we typically wish to access perhaps thousands or millions of objects, going across several entity bean types.
Finder methods can help us here, but only if we wish to access information from 1 type of entity bean.
I know what you are thinking: why not just get a Datasource reference and execute some SQL?
This approach is not very 'clean' in terms of EJB. You need to have knowlege of the underlying database schema and the concepts in the SQL domain may not map directly to the concepts in the EJB domain.
Additionally, this assumption is based on the fact that a SQL database is being used.
EJB 2.0 has provided for this with the introduction of EJB QL.
Therefore what I propose is some kind of extension to EJB which uses EJB QL to perform complex queries that produce results in a ResultSet like interface.
The container may then perform bulk queries on EJB data, without having the overhead of having to actually 'load' the EJB objects and hence optimise.
This makes it possible to write applications which can produce reports that are independent of the persistance engine being used.
If reports are being considered, then it might also be worth considering bulk updates.
The main flaw I can see in my proposal is how BMP entites are managed.
I think this problem needs a solution, and we should approach Sun with it.
Does anyone else have a view point on this? Has anyone thought of a better way of solving this problem?
