The first group of things I'd be caching would be things like states, counties, cities. These are all in a database or legacy system somewhere. So for those it'd be easy to come up with a key. Then there are some queries that I would hypothetically like to cache. For these, I was thinking of using criteria objects as input to the methods.. For example, instead of :
List<Business> searchBusinessByLocatation(String businessName, string state, string county, string city, ...); I was thinking of defining some kind of search criteria object: List<Business> searchBusinessByLocatation(BusinessByLocationCriteria criteria); Then I could just use this object as the key. If anyone did that search again, it would be in cache. These are just a couple ideas I'm throwing out here. It started out as a real problem from a real client but for now I'm just playing around with HiveMind so I'm kind of inventing stuff myself to see how I can cache it. Because there are things to cache at several different levels. The basic data, such as cities in a state for example, and also complex queries. I've downloaded HiveMind and have started playing with the samples. I'll see what I come up with. -Michael > -----Original Message----- > From: Johan Lindquist [mailto:[EMAIL PROTECTED] > Sent: Monday, March 28, 2005 10:46 AM > To: [email protected] > Subject: Re: Using Interceptors to implement transparent cache > > Agree - i was trying this out a while ago and the only > problem i ran into was that you have to make sure the key you > generate are unique and not to slow to generate ... It is > fine with strings and the natives, but when you run into > trying to cache requests based on more complex objects, the > key generation becomes a little trickier (what values to use, > cause toString for example could be to slow, or return bad > keys) ... But nevertheless an interesting topic :) > > Johan > > On Mon, 28 Mar 2005 03:35:29 -0500, James Carman > <[EMAIL PROTECTED]> wrote: > > > It's definitely doable using service interceptors in HiveMind. I > > assume you have a way to key the cache, based upon the parameters > > passed to the method invocation. You would also have to > have a way to > > identify which method invocations' return values you want > cached. You > > could either do that programmatically (maybe using a JDK5 > annotation) > > or via a configuration point. Sounds interesting. > > > > -----Original Message----- > > From: Michael [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 28, 2005 3:26 AM > > To: [email protected] > > Subject: Using Interceptors to implement transparent cache > > > > > > I've used Pico & AOP so I am really interested in HiveMind's use of > > interceptors. I'm currently thinking of a way to > implementing caching > > in a system without a database. An AOP approach seems > straightforward > > but if I can use HiveMind's interceptors it seems I may be able to > > avoid AOP. I'm curious if anyone has any experience with > this, or if > > anyone has any ideas? > > My idea is to add an interceptor to look in the cache for an object > > and if it's there, return the object and if not then > continue with the > > service's method and then at the end put the object in the cache so > > it's available the next time. > > > > Regards, > > Michael > > > > > > > > -- > > This E-mail is confidential. It may also be legally > privileged. If > > you are not the addressee you may not copy, forward, > disclose or use > > any part of it. > > If you have received this message in error, please delete > it and all > > copies from your system and notify the sender immediately by return > > E-mail. > > Internet communications cannot be guaranteed to be timely, secure, > > error or virus-free. The sender does not accept liability for any > > errors or omissions. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > -- > you too? > -- This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
