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]



Reply via email to