Ian,
I agree that database caches are highly effective and that arbitrarily
adding object caches in front of them is not wise. On the other hand,
the systems you describe are typically highly tuned operational systems.
In today's world, many multi-tiered apps are layered over a hodge-podge
of systems that were never designed to support the particular function
the apps provide. In these cases it is often effective for a component
to cache parts of its state within a transaction, or to batch updates
within a trasaction. The entity load/store paradigm allows a developer
to do this simply. This is more than a theoretical advantage.
-- Mark
Ian McCallion wrote:
>
> 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".
===========================================================================
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".
