Marc San Soucie wrote:
> Ian McCallion writes:
>
> > The whole idea of optimisation by caching in the JVM to avoid DB access
and
> > (re)construction of objects from data is somewhat suspect. It can and
will
> > be done but it only works in special cases where there is a clean
> > relationship between database rows and EBs and is fundamentally
> > non-scaleable to multiple JVMs and clusered systems.
>
> On this last point, the folks at Persistence and here at GemStone might
> differ with you a bit.
>
> GemStone/J's caching capability is based on an integrated persistent
object
> store, accessible concurrently - and transactionally - from a large
number
? of independent Java VMs on one or more distinct machines, via shared
> memory. Yes, the relationship between object models and the relational
data
> they represent can be tricky to establish and synchronize, but once
cached,
> our system does allow scaleable access to the cache from multiple JVMs
and
> clustered systems.
This is excellent. I had assumed that the OODBMSs would have built a
scaleable object cache for their own database. However if I understand
correctly, with Gemstone you can also use the cache to hold objects
constructed from relational data. Presumably the objects are serialised to
and from multiple JVMs on multiple systems as needed. Presumably too the
O-R mapping is taken completely out of the Java and EJB evironment so that
the relational DB appears like an OODB.
Have I got the right idea? If not I'd appreciate a bit more clarification.
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".
