Mark Hapner wrote: > 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. It's certainly true that today's 1000 transactions/second systems are highly tuned. The point of my comment was that the databases can handle very large workload and that therefore the problems that have lead to app servers caching are not database problems. Your observation does not alter this. > 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. IMHO this "advantage" is even more theoretical because: 1. Direct users of the legacy app can change the data and there is no way to notify the EB of the change (similar to the "DbIsShared" situation). 2. Legacy apps frequently (almost invariably) have the notion of a multi-transaction conversation such as run (txn a) to select the business entity to work on, (user think time), run (txn b) to read the selected data and possibly obtain an application-level lock, (user think time), run (txn c) to update the data and free the lock. Session beans provide the equivalent of a conversation in EJB so a stateful SB can be used straightforwardly to wrapper the legacy app. However the semantics of (txn a), (txn b), (txn c) cannot be mapped to the events and methods of an EB. (Note that as there is a strong analogy between a legacy "conversation" and a session bean, if you are unfamiliar with legacy systems you can get an idea of the problems by trying to imagine wrappering a stateful session bean with an entity bean. Doesn't really work, does it?) 3. The legacy wrappering requirement is usually to provide a good OO representation of the legacy app's capabilities, not to provide a partial and inaccurate representation of the legacy app as something it is not, namely a database. Thousands of "legacy" systems are being internet-enabled today - in weeks rather than months - by wise reuse of existing legacy application logic and wise use of the legacy application development capability. 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".
