Mark Hapner wrote:
> The major overhead in most components is the database lookup and update.
> MTS components don't provide any optimization of this function. They are
> just harder to program because developers are forced to use stateless
> functions. The EJB entity model does not require any extra database
> overhead and since the EJB container understands what the developer is
> trying to achieve it can help optimize the work.
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".
