Hey, I rewrote a lot of code other programmers in my team did the way I understand you used (call finders everywhere and loop though collections) and with no exception they became orders of magnitude faster on our benchmarks and on the users point of view. Of course, you have to spend serious time tunning your O/R mapping to use the container lazy loading features, caching and so on.

Well, before going too far down this path, remember that you''re getting a tiny, tiny snapshot of what the application does, and you''re making decisions about how well the application performs for its chosen function without any data.

Mr Nomad, I hope you realize the burden you''re putting on your database by not using CMR and "enforcing" relationships on session facades. To get performance from relational databases you have to let the server do the work and not take small bits of data and process them yourself.

I see many J2EE projects done this way, and they remember the old days of clipper: instead of using the power of a declarative language such as SQL, iterate over the data and do all processing yourself. Replace few lines of easily undestandable SQL statements with dozen lines of procedural code, dificult to maintain, and throw away any benefits the SQL execution plan optimizer could bring to you. Then people start complaining J2EE isn''t productive or fast. :-(

This remembers me another point of the standard I''d love to see finished by the JCP: the EB-QL language is yet too limited, forcing me to use vendor (proprieraty) alternatives to code my find/select methods, or to write SQL directly. At least, the standard should tell how a developer should provide the SQL code for these select methods when EB-QL is not enough.

I am very surprised nobody else complains about the current (and previous) state of CMP, CMR and EB-QL. Maybe few people out there understands the container shoud get the data, not the application code.

For one thing, I use a simple schema and not CMR, because I still don''t think CMR has been done well yet. Relationships are enforced by session facades. Past that, there''s not much to it. CMR was one are where the spec didn''t go into enough detail to be useful.

So tell me what''s the magic that allows your CMP beans to be deployed, without changes, on any app server? Even Xdoclet doesn''t provides that (relationships still have to be coded on server-specific way).

Surprisingly, CMP entity beans. And they''re working fine, thanks... even scaling well.

Mr. Momad, I guess you have not used CMP Entity Beans. :-) What are you using for persistence?

Mr. Lozano... I hate to tell you this, but I''m working on an application, based around the specs (I''m writing the deployment descriptors based on the published specs, literally) and deploying on three servers right now. This includes EJB, application clients, JMS. While I''m annoyed that there are issues with deployment based on the spec (primarily in classloaders), I''m able to compensate without too much trouble. The specs are workable, but incomplete.

Although the changes on the JCP reflected by the new J2EE standard are wellcome, I wonder why the JCP cannot finish this spec so I can deploy my EJBs on any app server on the market. If I use CMP entity beans I am tied to a vendor, J2EE specs do not tell how should the container map Entity beans to relational tabes, and I am stuch with a proprietaty, one-vendor-only mapping.

On the first release of the specs including CMP it was understandable: half a standar is better than no standard. But now this is unacceptable, but things are this way because vendors cannot give their customers real freedom to change them for another vendor and keep thinking on ways to lock customers to their products.

Many people are runnig away from CMP to JDO for this reason. They just get stuck with a proprietary product from another vendor, as the JDO specs also do not define the OO/Relational mapping descriptor.

So, please, JCP members, give us real, complete open standards, and not just "advertisement" standards.