see below > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ned Wolpert > Sent: 28 September 2001 16:54 > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Performance > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the places where I worked, we did this by using JMS to > send messages > when an object was updated to other servers using TopLink. When > they got the > message, they flushed the object out-of-the cache. It actually > worked pretty > well, and I've got the start of a variation of that concept that > I want to use > with Castor. Of course, you cannot currently remove objects from a castor > cache, so it will have to wait.
As you mention, I don't think you can explicitly remove an object from Castor's cache, but surely you can get the same effect by calling db.remove(object) ?? If the object is already deleted in the underlying db, then it will silently "not delete" the row, and Castor should remove it from the cache. If your JMS message specifies an update or a new, then you call db.load(...) instead to reload/load the objects state. I reckon you could stick a JMS (or whatever) clustering layer on top of Castor without having to add a new "unload" method. Or am I missing something?? (Always quite possible :) ) > > It is a nice feature... > > On 28-Sep-2001 James Higginbotham wrote: > > I have seen a this problem solved in TopLink by using a multicast > > approach, where each instance of Toplink sends an event to all other > > instances with the PK and type (or similiar event data) of the data > > modified. Whenever a retrieve of the data is requested, the particular > > record is known to be dirty and a refresh is made. > > > > Maybe this is a feature best suited to a "commercial grade" version of > > castor, or by someone with a lot of time to write and debug this logic. > >:) Its a nice feature, but one that is rare even in commercial packages > > outside of TopLink. > > > Virtually, > Ned Wolpert <[EMAIL PROTECTED]> > > D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7tJ0JiysnOdCML0URAmF+AJ9QyhPdCaB0a2uPChtCDCg2T2s4EQCfRJL3 > BQ/cZ+ofVSThuvRPgUKlxbE= > =5XTR > -----END PGP SIGNATURE----- > > ----------------------------------------------------------- > 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
