Tim, Maybe I'm misunderstanding, by clustering do you mean the distributed cache?
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: 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." 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
