Doug,
Responses below...
Regards,
-Chris.
> -----Original Message-----
> From: Bechtold, Douglas [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, January 24, 2000 8:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> 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?
>
It would be transparent to the programmer whether only state is cached or
whether the bean instances themselves are cached. Standard EJB CMP semantics
must be followed in either case.
> 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?
>
Exactly.
> If the container can do this for CMP, what is left to overcome in
> order to support BMP as well?
>
In BMP, the developer is responsible for IO to the datasource. The container
doesn't get between the bean and its IO, so autmatic cache enhancement from
the container isn't really possible. However that doesn't mean the container
can't provide cache facilities that the BMP programmer could use explicitly
in the BMP case.
> 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".
===========================================================================
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".
