I would also use a @SessionState pojo. The approach of the service having a map wouldn't work in a clustered environment.
On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson <erickerick...@gmail.com> wrote: > POJOs can be stored as @SessionState variables *if* they're > serializable (as I understand it), would that work? > > I can't weigh in on the pros and cons of memory usage etc over > your injected service idea, but using @SessionState would > be simpler code-wise until you had reason to change.... > > FWIW > Erick > > On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan > <j...@peritussolutions.com>wrote: > >> I'm trying to work out the best approach to passing a pojo around a system >> that is to be used for caching some user relevant data (keys only, and >> otherwise minimal amounts of information) on a per-user basis. The data is >> to be used in a large number of db queries in the system (various persisted >> config demarcated by company / division codes) during a user's session, and >> as such I don't want to be reloading it from the db on a per-user basis >> each >> time. I would like to use a pojo, and do an initial load of the data when >> the user logs in (or lazy-load and cache on getter access of specific >> data), >> and then have it available around various parts of the system (esp. the >> service and possibly DAO layer). Can some of you more experienced >> Tapestry5 >> users advise on how best to approach this scenario? Is an injected service >> containing a map of pojos keyed on user a bad idea? Thanks for any >> suggestions. >> >> Regards, >> Jim. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
