> -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: 22 June 2005 11:54 > To: Struts Users Mailing List > Subject: Re: Storing data in session scope > > > On 22/06/05 08:54 Pilgrim, Peter wrote: > >> What data do I need to store???. Data that it has to be updated if > >> the user goes to a module which update that data but in database. > >> So If the user updates the data, it has to be updated automatically > >> in the application scope. > > > > > This is different kettle of fish. You need to implement in your > > application architecture the "Reference Data Cache" idiom. > > > > In this case you do not need to store data in application scope at > > all. Rather all your database access comes through business data > > access delegate. > > Peter, > this caught my eye because I wasn't aware of this one - > "Reference Data > Cache" sounds like a useful pattern and one that I have probably > implemented independently. > > Do you have a reference (bad pun) so I can check out this out > ? I just > searched thro Gang of Four and Marinescou's EJB Des. Patts. without > seeing anything similar. > > > Adam > I am unsure if this is a pattern or idiom. If it is the former I thought I saw in a borrowed copy Java Patterns, one of Mark Grand's epic bestsellers. Possibly in Java Enterprise Patterns by Wiley.
Actually the idiom is simply cache or the flyweight with a little modifications for web applications. The data access object pattern is re-use to make sure that every request for data goes the cache. The actual cache implementation is irrelevant TTL (time-to-live expiration times), SoftReferences (garbage collection) and/or destroyer Thread. For Web application you need to front-end your cache in control administration, or synchronise the cache from the database or because an external program has update the database behind the cache's back. YMMV because if you have an external (legacy) process that creates transient static data periodically then you need to architect some form re-synchronisation. Throws out the old cache, create a brand new cache. For example this could be a MDB (JMS) or come a J2EE connector. This is the use-case that takes the actually takes simple-in-memory and in-same-VM Java caching into the enterprise world of reference data. As I said before, first if you decide to use reference data cache, then you must make sure that you never access the data by going around the back of it. (What would be the point, then?). Second decide on compromise if your reference data does change regularly, and especially if it is external legacy process. Actually Wendy's suggestion ehcache would be good for an implementation. The same technology used by the Hibernators. HTH -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
