struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vic Cekvenich <>
Subject Re: some best practices questions
Date Mon, 19 Jul 2004 15:40:59 GMT
My comment would be that *data* caching should be done in the data layer 
(like ibatis, hibrenate, whatever).

Pilgrim, Peter wrote:
>>-----Original Message-----
>>From: Michael McGrady []
>>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 
>>>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.
> 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:
For additional commands, e-mail:

View raw message