How will this eventual CMP implementation work? Would the instance of the
entity bean itself be put in the cache, or a just an object representing the
state of the entity bean? Either way, isn't it the container that would
have to realize that when the entity bean is requested, that the first thing
to do would be check the cache to see if the information is there already,
correct? If the container can do this for CMP, what is left to overcome in
order to support BMP as well?
DB
-----Original Message-----
From: Chris Raber [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 22, 2000 10:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Caching of read-only DB contents in an EJB
Bingo! This is why write through caches of entity beans don't work in a
distributed environment unless you also have a distributed shared cache.
<vendor>
This is the problem GemStone/J can solve. It is not as fully transparent as
some would hope, but eventually we will have a CMP implementation layered on
this that makes it totally transparent to the bean developer. Today explicit
cache pinning is required, but judicious use of isolation layers can keep
your beans from being "proprietary".
</vendor>
-Chris.
> -----Original Message-----
> From: Paul Hodgetts [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, January 21, 2000 2:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> Assaf Arkin wrote:
>
> > Paul Hodgetts wrote:
> >
> > > Even though this may be vendor specific, how does this all work
> > > in a clustered environment? Are the object caches in each
> > > container kept consistent across multiple container instances?
> > > If so, how is it done - what are the limitations?
> >
> > They should through shared locking and other mechanisms of consistency
> > checks. There are no limitations, but you pay a penalty in performance.
> > It's not going to be slower than using a database, but it won't be as
> > fast as Hashtable either.
>
> The specific scenario I'm thinking of is this:
>
> 1. Container A instantiates an entity bean with a PK of 26. This
> entity is not in Container A's cache (in its VM), so it reads
> it from the database and caches it. The entity is used, and is
> eventually passivated.
>
> 2. Container B instantiates the same entity bean (PK 26). It's
> not in its cache, so it reads it from the database. After
> updating some fields in the entity, the entity is stored back
> to the database.
>
> 3. Container A gets another request to use the entity (PK 26).
> It finds the entity in its cache, and uses the cached entity.
> But this copy is no longer up to date, because it doesn't
> reflect the changes made through container B.
>
> Obviously, something needed to happen after step 2 to cause the
> entity in container A's cache to be invalidated so that it will
> refresh it from the database on the next access. If the cluster
> is the only thing that will be accessing the entity, then these
> notifications can be generated from container to container,
> perhaps using JMS. If arbitrary apps can update the database,
> then the notification would have to come from the database,
> perhaps via triggers or some such.
>
> Is there any CMP product on the market that handles this scenario
> (assuming that the cluster can own the database for now)?
>
> Thanks,
> -Paul Hodgetts
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
