Assaf,
I'll address the alternative approach you outlined in your other post in
detail (time allowing). In short, database locks are only good for the time
span for which we hold onto a database connection. In the world of
datasource connection pooling, locks are are usually only good within short
transaction boundaries. To handle concurrency detection for a short
transaction model (where the user is outide transaction during think time),
soft locking is required (e.g. by using timestamps, counters, state
comparisons...). I assume this is what you mean by "dirty checking".
An issue I see with dirty checking as you have suggested it is that every
time we want to read from cache we have to also read from the datasource of
record to check cache coherency. The cost of the coherency check largely
outweighs the benefit of caching in the first place. So in the case where
there are applications writing the datasource without going though the cache
(e.g. they are not playing our write-through game with us), it is probably
not as worthwhile to cache in the first place, unless some amount of
staleness is acceptable.
"There are a hundred ways to skin the cat". Hopefully I have not offended
any cat lovers today... No particular approach is 100% correct, it's a
question of best fit for particular requirements.
Regards,
-Chris.
> -----Original Message-----
> From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, January 22, 2000 1:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> Can you explain to me why you would need a distributed shared cache if
> you can use database locking and dirty checking which allows you to get
> it working even in environments which are not pure EJB?
>
> arkin
>
>
> Chris Raber wrote:
> >
> > 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".
