c below > -----Original Message----- > From: Matthew Baird [mailto:[EMAIL PROTECTED]] > Sent: 01 October 2001 18:47 > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Performance) > > > Tim, > > Maybe I'm misunderstanding, by clustering do you mean the > distributed cache? yes > > If so, I don't see a reason why NOT to do this. According to everything I > know and have read, there is no way to run 2 different boxes with our app > server (J2ee) code on it with two separate installs of castor both hitting > the same db and have the app run properly:
True - we're actually in a similar situation. If you're willing to lose Castor caching, and just use it for the o/r mapping then you could turn caching off, then your app will work ok. You'll probably agree this is a bit drastic though. We're actually considering (as someone else mentioned) slapping a JMS topic on top of the various instances of Castor (and sending delete and update messages (along with the object class identifier and object id)). This should be reasonable easy to do. > > 1. I HAVE to have the cache on to support long transactions. > 2. updates from other VM's running castor will not show up in all of the > castor caches. > > The only solution I see is I would have to change my code > (somehow) to catch > the object modified transaction, and then reload the object? > > Please explain what you mean by "there are probably better > and cleaner methods which can be built into the code at a more fundamental > level." > The JMS approach mentioned above which requires no change to Castor code is probably ok, in our application where reads outnumber writes, and throughput is quite low but IMHO may not be the best generic generic caching strategy. > m > > -----Original Message----- > From: Tim Fox [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 01, 2001 10:05 AM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Performance) > > > c below > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ned Wolpert > > Sent: 01 October 2001 17:34 > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] Performance) > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On 01-Oct-2001 Tim Fox wrote: > > >> When the object is new or modified, call the db.load(). However, > > >> I guess my first question is why doesn't this load from the > > cache like a > > >> OQLQuery call would do? When the db.load() call is made, does the > > >> resulting object get cached? > > > > > I think you're right - you'll need to do an OQLQuery (as this > > bypasses the > > > cache) rather than a db.load (which looks in the cache first) > > > > Now I'm really confused. Originally, I had thought that both techniques > > (OQLQuery and db.load()) load from the cache. I think I asked > about this > > specifically awhile ago. So, here's my question to 'those that know'... > > > > Do the objects that are returned from an OQLQuery get cached? Is > > it the case > > that only objects returned from db.load() are cached? Can > > someone verify that > > this is the case? > > The objects returned from an oqlquery or by db.load are cached > depending on > whether the class in question is declared as cacheable (ie not > no-cache) in > the mapping xml file. > > However when I execute an OQLQuery - it goes straight thru the > cache to the > database - there's a simple reason for this: > if I do select * from ..., then I can't assume all the objects are in the > cache so I must go to the db. > > db.load looks in the cache first, and if not there, in the db. If > you think > about it this makes sense, since when calling db.load you specify the > object's id - hence you can say definitely whether it's in the > cache or not. > > You will never want an OQLquery to query the cache only - this > doesn't make > sense (actually it makes sense only in the single case when your entire db > is loaded into your cache!). > > The cache should be transparent - ie you don't specify whether > you are using > the cache or not. db.load and oqlqyery work in this way. > > I don't believe an evict function is technically necessary, I think > everything necessary is there already. > > Having said that though, just because it may be possible to build > clustering > on top of Castor, doesn't mean it should be done - there are > probably better > and cleaner methods which can be built into the code at a more fundamental > level. > > > > > > > > > Tim- If this is the case, then I still have a problem with app-layer > > distributed caching. My code needs a consistant way to retrieve > > objects. I can't use db.load() sometimes (when I want the cache) > > and OQLQuery > > other times (when I don't.) Especially if I want to notify > > different castor > > processes of changes to the cache. Basically, until the evict > function is > > there, app-layer cache control is impossible. > > > > > > 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 > > > > iD8DBQE7uJrriysnOdCML0URAjZgAJ418Q+AeQZq7Ns5zFDvc9gHnvwB7wCfaf5G > > ngcIT+9pbJuE6oN+36nmcFs= > > =lnGB > > -----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 > > ----------------------------------------------------------- > 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
