I couldn't agree more. Current O/R mapping technology is extremely high in
unnecessary overhead, including the use of dynamic sql, failure to use the
RDBM's ability to optimize reads across multiple tables (I've seen 2 orders
of magnitude reduction in object realization time when this is fixed!),
and, as Ian points out, very high procedural overhead in reading and
setting database fields.
I also endorse the notion that there should be a uniform standard for
serializing from or to RDBM's into java objects. We had this years ago in
network DBs (the data structures weren't java of course, but the principle
is the same).
At 04:31 PM 8/16/99 +0100, you wrote:
>It is misleading to imply that database systems causes "overhead" and that
>in order to achieve acceptable performance the application or application
>server must perform caching and avoid calling the database whenever
>possible.
>
>As a proof by example of my point, procedural transaction processing
>applications don't cache and always read and update the database for each
>(update) transaction, yet worldwide, there are many large single system
>applications that consistently achieve 1000-5000 unpredictable, highly
>varied and non-trivial transactions per second on very large databases.
>Furthermore, these applications could be scaled up to new heights without
>change to the application code by exploiting clustered systems. This level
>of performance is achievable because database systems do their own caching,
>avoid reads from the disk and defer writes to the disk (see footnote).
>Moving caching into the application might improve performance but would
>limit the application to a single system and require the database to be
>dedicated to the application.
>
>So, if optimising by avoiding database access is not necessary and
>compromises scaleability, why has it gained popularity for OO applications?
>The answer is that applications which do it are also avoiding the currently
>highly inefficient step of construction of an Object from Data. I'm
>guessing the numbers here but I suspect that most java Object-from-Data
>implementations take thousands to hundreds of thousands of instructions
>compared to the tens or hundreds of instructions needed for the procedural
>equivalent of copying the data into a cobol structure.
>
>Returning to the EJB/COM+ debate, a theoretical advantage of EJB over COM+
>is that EJB provides a framework (Entity Beans) for doing Object-from-data
>whereas COM+ does not. But this advantage will remain theoretical until
>efficient Object-from-data systems emerge. Use of static SQL, and an open
>form of serialised java object which database systems can construct
>directly (and perhaps cache??) seem to be the way forward. Fiddling around
>within the EJB container to avoid JDBC calls is not.
>
>---------------------------
>(1) The general scheme uses a "buffer pool" of frequently needed index and
>data records and a transactional log which contains both backout and redo
>information needed in the event of a system or database crash. I/O to the
>log is highly optimised to reduce latency because it is forced at
>transaction end. Updates to the disk copy of the database are not done as
>part of a transaction at all but to free up buffer pool space and to hold
>down the amount of redo needed after a system failure, usually on low
>priority processes using "spare" processor cycles. Cluster support requires
>a cluster-wide locking facility. Each system keeps its own buffer pool
>which is kept consistent with other pools in the cluster by signals between
>the pools.
>
>
>Ian McCallion
>CICS Business Unit
>IBM Hursley
>[EMAIL PROTECTED]
>Tel: ++44-1962-818065
>Fax: ++44-1962-818069
>
>===========================================================================
>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".
>
Steve Demuth
Director of Technology Research
Artemis Alliance, Inc. An Inprise Premier Partner
2750 Lannon Hill Road
Decorah, Iowa 52101
651-227-7172 (Typically Mon-Tue) or 319-382-0593 (Wed-Fri)
===========================================================================
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".
