struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <tiwari.raj...@wipro.com>
Subject RE: some best practices questions
Date Mon, 26 Jul 2004 04:26:54 GMT

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: puneet.a@tcs.com [mailto:puneet.a@tcs.com]
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: puneet.a@tcs.com
Website: http://www.tcs.com




Mike Duffy <mduffy_lists@yahoo.com>

07/19/2004 11:14 PM


Please respond to
"Struts Users Mailing List" <user@struts.apache.org>


To

Struts Users Mailing List <user@struts.apache.org>


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 <cekvenich.vic@portalvu.com> 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:mike@michaelmcgrady.com]
> >>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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>



               
                                
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


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 Mailadmin@wipro.com
immediately
and destroy all copies of this message and any attachments.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message