> From: Steve Muench [mailto:[EMAIL PROTECTED]]
> For result sets whose data is static over the span of an
> application "day" (States in the U.S. for example), or for simple
> lookup by primary key, you will gain something from the cached
> representation in the middle tier. However, as soon as you begin to
> build a real application that needs complex WHERE clause evaluation
> where the criteria are changing by user and have to deal with the
> inevitable fact that other applications besides your EJB client will
> be modifying those same tables, then for the EJB container to really
> add value here, it needs to become a full-fledged database to really
> unload the work off the back-end database of evaluating arbitrary
> queries (not just equality matches against key values).
Agreed.
> Regardless of the quality of your EJB container, it will be a long
> time before any middle-tier application server can deliver the
> performance of today's relational databases for querying enterprise
> data.
Yes, however we're not talking about querying, but sorting. I can think of
several cases where I want the sort to be implemented on the Java side.
> Again, if the majority of the cases are looking up all attributes of
> an object by primary key, or doing simple equality predicates, then
> you are right. But most apps I've consulted on, like the 40-50 huge
> applications suites built by the Oracle Applications teams, need the
> ability to work with the full power of SQL and the ability to
> automatically tie that back into their entities.
Precisely. How could you "tie that back into their entities" if the sort is
performed on the database? Unless your container and your database use a
private SPI to communicate, this cannot be done. Well, it cannot be done
without a cost, cost that could be avoided if the sort is performed on the
container side.
> This seems like a doomsday scenario for developers. Every time I've
> worked on a project that tried to treat the database as a black box,
> putting blind faith into a magic conversion layer to convert from a
> "query in terms of objects" into a query in terms of tables, the
> performance has just never been able to match the hand-tuned SQL,
> understandably.
This statement used to apply to C compilers, in a time when developers could
actually do a better job by writing assembly code themselves. We've come a
long way, and I'm optimistic that CMP implementations will follow the same
path.
As you said, time will tell.
--
Cedric
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
