Assaf,
One conceptual disconnect we may be having is the the GemStone/J cache
itself is transactional. This means updates to the cache and other XA
resources are performed in a 2PC distributed transaction. Does this ease
your worry of coherency issues?
Of couse we still have the issue of optimistic locking/dirty checking for
updated that are buffered between transactions... That pattern applies
whether we have distributed caching and XA or not...
-Chris.
> -----Original Message-----
> From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, January 26, 2000 6:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching of read-only DB contents in an EJB
>
> > 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.
>
> That is what I refer to as dirty checking, which I don't to synchronize
> across VMS, more on why below.
>
> > I think we have a terminology collision here. I equated dirty checking
> and
> > optimistic locking...
>
> I am using dirty checking with optimistic locking. Optimistic locking
> assumes that concurrent updates will not happen, but if they do you
> bette check them. Pessimistic locking prevents them from happening.
>
>
> > 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...
>
> Here is why I decided to not do distributed cache on top of RDBMS (at
> least not by default).
>
> The distributed cache only works when all your access to a table is done
> through the CMP layer, or whatever other API you give. Once a session
> bean, JMS message, plain JDBC in a Servlet or some cron job does an
> update to the database all is gone.
>
> Once you start with the simple assumption that anything can happen and
> that your commits can fail (!), you limit optimistic locking mode to the
> cases where concurrent access is a low possibility. Low possibility
> means almost zero gain in replicating these changes or distributing the
> locks.
>
> If you do need the locking guarantee then only optimistic locking (i.e.
> SELECT FOR UPDATE) works, in which case the cache is totally redundant
> (I just use it for object rollback). So no need to synchronize either.
>
>
> Obviously you guys have put a lot of brain power into this, and
> certainly an application that only accesses the database through this
> API will benefit from distributed locking and caching. But such an
> application must be designed with these assumptions in mind. They don't
> go against the spirit of EJB, but they are certainly not portable to
> other environments.
>
> arkin
>
> >
> > > 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".
>
> --
> ----------------------------------------------------------------------
> 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".
