Nicholas,
We call it a persistent cache because, well, it's persistent! That means
when we cache we back up this cache with fault tolerant storage.
You can for example use persistent q's for store and forward transactions to
your back end systems. This way you have guaranteed delivery...
-Chris.
> -----Original Message-----
> From: Nicholas Whitehead [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, January 26, 2000 9:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> Chris;
>
> I am jumping in mid-discussion so please bear with me
> if you have addressed this.
>
> I am interested in keeping an in memory cache, but my
> concern, which you may have resolved, is what happens
> when unpersisted (DBMS) transactions are sitting in
> cache and there is a system failure ? Is your
> architecture simply transaction loss tolerant, or are
> you persisting your in cache changes somewhere other
> than the database ? If so, is this persistence model
> speedier than the DBMS ?
>
> //Nicholas
>
> --- Chris Raber <[EMAIL PROTECTED]> wrote:
> > Assaf,
> >
> > Here we go again ;-)
> >
> > Assaf said:
> > > -----Original Message-----
> > > Chris Raber wrote:
> > > >
> > > > 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".
> > >
> > > This has nothing to do with connection pooling,
> > you can hold onto a
> > > connection for as long as you hold onto the
> > transaction, and you can
> > > hold onto the transaction (and connection) across
> > multiple invocations
> > > on a stateful session beans. (Not that I recommend
> > that anyone do that).
> > >
> > Yes of course. I was refering to the result of
> > holding onto the transaction,
> > i.e. that the connection would be held on to. We are
> > in violent agreement.
> >
> > > So the question is how do you perform updates in
> > memory not within a
> > > database transactions. I have the code to do that,
> > but I couldn't find
> > > anything in the EJB or ODMG API that allows me to
> > do that. Once you're
> > > outside the context of a transaction, how do you
> > lock the objects.
> > >
> > Right. This is where you have to use a "soft lock".
> > For example maintain a
> > counter or timestamp on the corresponding database
> > row, and check for
> > collisions on update. Tons of stuff in the archives
> > on this.
> >
> > > I can easily add an API for that, but as long as
> > it's not industry
> > > standard, I'm going to stay clear of that.
> > >
> > It would be nice if the technical services layer of
> > the architecture handles
> > this for you. In our Developer's Guide, the OR
> > mapping layer has this built
> > in... As you say it is "non-standard", but it's not
> > proprietary GS/J code
> > either. Just a bunch of Java code that anyone could
> > use for OR mapping...
> >
> > > > 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
> > >
> > > No. Dirty checking works at store time, it's
> > optimistic locking model.
> > >
> > I think we have a terminology collision here. I
> > equated dirty checking and
> > optimistic locking...
> >
> > > If you want to make sure your object is
> > synchronized before starting to
> > > work with it, forget about soft transactions. Work
> > with your EJB in the
> > > context of a transaction, specify exclusive
> > access, and dirty checking
> > > will never happen.
> > >
> > > If you are performing operations outside of
> > transaction boundary,
> > > there's no alternative to dirty checking.
> > >
> > Yup.
> >
> > > I know there are solutions in between these two
> > extremes, but they don't
> > > yield easily to a CMP model.
> > >
> > I haven't thought about it in a CMP context yet. I'd
> > be interested to know
> > how current CMP implementations handle optimistic
> > concurrency and buffered
> > updates from outside transaction.
> >
> >
> > >>> snip some arguments about caching... I'm
> > getting tired.
> >
> >
> >
> > > But all of these arguments don't explain to me why
> > you need a shared
> > > cache. I don't see where the shared cache comes
> > into play, and I don't
> > > where it gives you any transactional assurance.
> > You can prevent two
> > > servers form affecting the same bean, but you
> > cannot avoid the database
> > > being updated concurrently.
> > >
> > The shared cache is a convenience and a performance
> > booster. If we update a
> > cached object on one machine, changes are propogated
> > to other machines as
> > required. This way we don't have the potential that
> > the remote machine has a
> > stale view of the cache. The next time a transaction
> > involves the updated
> > object on the remote machine, the new state is
> > already there...
> >
> > > arkin
> > >
> > >
> > >
> > > >
> > > > "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.
> > >
> > > --
> > >
> >
> ----------------------------------------------------------------------
> > > Assaf Arkin
> > www.exoffice.com
> > > CTO, Exoffice Technologies, Inc.
> > www.exolab.org
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
> >
> >
>
> =====
> "Suzie, Suzie, Suzie, Suzie
> Suzie, Suzie Greenberg"
> Suzie Greenberg, Phish
>
> --
> Nicholas Whitehead
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
> ==========================================================================
> =
> 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".
