Just in continuation to discussion, as Peter says, My comment would be that *data* caching should be done in the data layer
> (like I would like to make small comment on the same, Data Caching should be keeping in mind that kind of data we need to cache. If cached data is of presentation specific (like rendering drop downs etc), caching at presentation layer (in servlet context ) would be just fine. But if it is of back end processing type (i.e. Currency Exchange Rate etc), it will be advisable to maintain at data layer. - regards Raj (+91-11-31261821) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 9:15 AM To: Struts Users Mailing List Subject: Re: some best practices questions One of our application had more than 300 screens, we used struts and most of those screens had a drop-down list. We stored all of them in servlet context, and every JSP got a copy of it in "pre-populate place holder". The peak user load was abt 500, and its working just fine...!!! Regards, Puneet Agarwal Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Mike Duffy <[EMAIL PROTECTED]> 07/19/2004 11:14 PM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To Struts Users Mailing List <[EMAIL PROTECTED]> cc Subject Re: some best practices questions What do you think of caching static or semi-static data that applies to all users (options in a drop down list, etc.) in the application scope? --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > My comment would be that *data* caching should be done in the data layer > (like ibatis, hibrenate, whatever). > .V > > Pilgrim, Peter wrote: > >>-----Original Message----- > >>From: Michael McGrady [mailto:[EMAIL PROTECTED] > >>Sent: 08 July 2004 09:14 > >>To: Struts Users Mailing List > >>Subject: RE: some best practices questions > >> > >> > >>At 12:36 AM 7/8/2004, you wrote: > >> > >>>For this particular use case I would either just use the session, or > >>>alternatively I would just look up the dropdowns from db > >> > >>each time and > >> > >>>accept the performance hit, but its (probably) not worth the > >> > >>development > >> > >>>time - including ongoing maintenance - to do anything overly > >> > >>tricky just for > >> > >>>a few dropdowns. > >>> > >>>my 2c > >> > >>The thing is, though, Andrew, these are recurrent issues and seem to > >>require a generic solution. Having a small manager in > >>application scope > >>which can create and monitor a scope which is not > >>application, not session, > >>and not request, is worth the while for these recurrent problems, I > >>think. The persistence of such a scope can be made a > >>function of the data > >>rather than the interest of the clients. That is worth > >>having to use on a > >>general basis, I think, and can be done with a very small performance > >>hit. In fact, my guess is that it would be a performance plus. > >> > >>Michael > >> > >> > >> > > > > > > Well this is astounding, because I looking at JCache JSR whatever? > > and looking at alternatives like OSCache for a caching the look up > > of login user accounts. So where the hell is JCache or the standard. > > > > If it was there, I think it would give you what you want? > > > > -- > > Peter Pilgrim > > Operations/IT - Credit Suisse First Boston, > > 10 South Colonnade, London E14 4QJ, United Kingdom > > Tel: +44 (0)207 883 4447 > > > > ======================================================================== ====== > > This message is for the sole use of the intended recipient. If you received > > this message in error please delete it and notify us. If this message was > > misdirected, CSFB does not waive any confidentiality or privilege. CSFB > > retains and monitors electronic communications sent through its network. > > Instructions transmitted over this system are not binding on CSFB until they > > are confirmed by us. Message transmission is not guaranteed to be secure. > > ======================================================================== ====== > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ForwardSourceID:NT000023F6 Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments.
