I agree: caching should be transparent to your code. Using iBATIS, you can make your entire DAO layer behave that way - each SQL statement can be cached independently, or they can be grouped as appropriate.
That is the approach I use. I make my action classes always go to my service layer to get data - ALWAYS. No caching in the web tier. In the service layer, I then have two options: 1) Delegate to the DAO layer (where caching can be easily implemented) 2) Get data from the DAO layer (cached or not) and process it for the view In a case where the processing in option 2 is expensive I push it in to a stored procedure. If someone is using a DB w/o stored procedures (like Access or MySQL), they are probably not real serious about optimal application performance. ;-) IMO, whether the data is cached or not is really irrelevant by the time Struts gets involved. Larry On Tue, 15 Feb 2005 11:52:21 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Caching or not is also a decision that you sometimes want to change > after you see your application used in anger for a while. I like to > provide a getter method on some application scoped bean that returns > things like this, so I can change my decision to implement caching (or > not), for any given set of data, without impacting the rest of the > application -- it just calls the getter whenever it wants that data. > > Craig > > On Tue, 15 Feb 2005 13:58:32 -0500, Soaring Eagle > <[EMAIL PROTECTED]> wrote: > > Without contesting the good points. I would say memory is cheap. For > > an application i worked on, we had about 6 different applications > > sitting on two 4 by 16 machines. The -xmx arguments of all apps put > > together came up to about 10 gigs RAM and the rest was left open. i > > dont think serious application owners care about money sunk on > > hardware. > > > > Further, I agree that caching requires an overhead in terms of keeping > > various clusters in synch or managing updates etc.. but clients can be > > kept transparent of all this. there may be a period of a few 100 > > milliseconds to upto a couple of seconds when clients may get dirty > > reads if the cache design allows it - but that could be a small price > > to pay over the general speed of cache access. > > > > Anyways - sorry for contributing to making this a totally non-struts topic! > > > > > > On Tue, 15 Feb 2005 11:03:01 -0500, Bill Schneider <[EMAIL PROTECTED]> > > wrote: > > > >> how do you manage cross container caches if you are clustered - when > > > >> you are using static members on classes? How do guarantee sameness on > > > >> different physical machines? We do have a few caches in our > > > >> application and are facing issues due to this design or an improperly > > > >> implemented version of this design. > > > > > > Also, be aware that caching can actually degrade application performance > > > in some cases. Everything you cache takes space in the JVM heap, > > > reducing what's left to process active requests. So it's possible to > > > lose more cycles in GC than you saved by caching in the first place. You > > > can just keep increasing -Xmx, but that can hurt you if the JVM starts > > > using swap space/virtual memory for the Java heap. > > > > > > If you're using a clustered cache, you also have the overhead of keeping > > > the caches on each JVM in sync. That adds network as well as processing > > > overhead for marshalling and unmarshalling cached objects. > > > > > > In summary, J2EE webapp performance involves a lot of tradeoffs. Caching > > > is important but has to be used judiciously to be beneficial. > > > > > > -- Bill > > > -- > > > Bill Schneider > > > Chief Architect > > > > > > Vecna Technologies > > > 5004 Lehigh Rd., Suite B > > > College Park, MD 20740 > > > [EMAIL PROTECTED] > > > t: 301-864-7253 x1140 > > > f: 301-699-3180 > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
