To properly do distributed cache management don't you need distributed transactions? Which means and implementation of JTA? Which starts to look a bit like an appserver. It seems like handling the cache would fit the
remit but not distributed transactions - at that stage you would want to use something like session beans or some other transaction mechanism. I guess if you compare all this to something like Objectstore then you could picture it as providing resource transaction 2pc facilities. Perhaps that is a good remit. Cheers. Jon John Wang wrote: > I think this is important too, however, I am afraid that castor's cache > interface is not open enough. Is there a way to invalidate an object from > the cache? > > ----- Original Message ----- > From: "Wes Biggs" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, March 08, 2002 5:53 PM > Subject: [castor-dev] Distributed cache management > > > Hello, I'm new to the list. > > > > I was reviewing some conversations in the archives regarding distributed > > cache management -- at one point it was suggested that a whitepaper > > describing the options be created. > > > > I need to use Castor JDO in a distributed, non-EJB environment -- > > multiple JDO instances on the application server tier will have > > connections to the same underlying datasource (in this case, RDBMS). I > > am primarily concerned with the problem of keeping caches in sync > > between the different app servers; it can be conveniently assumed that > > no external processes are directly modifying the RDBMS (i.e. not using > > Castor APIs). > > > > Has any additional work been done either to implement a shared cache > > invalidation/mirroring scheme or to further analyze the problem? Has > > anyone implemented their own hacks? > > > > I would be interested in contributing to implement such a mechanism if > > necessary. > > > > Thanks, > > > > Wes > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev
begin:vcard n:Ferguson;Jon x-mozilla-html:FALSE org:Omega Software Ltd.;Consulting adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:Director and Architect note:To see things in the seed, that is genius. - Lao-tzu x-mozilla-cpt:;-4608 fn:Jon Ferguson end:vcard
