I would follow this guide: http://tapestry.apache.org/tapestry5/guide/appstate.html and make my own app state object, UserSession, which would contain the needed per user data. (The keys anyway.) There can be services that provide data based on these keys, and those services should also take care of caching or more preferably use cache service(s) to do the caching. Cache service can be implemented using ehcache (http://ehcache.org/) for an example.
Make interface that the user session implements, then use this interface in your service and dal methods as a parameter. This way your system is also cluster ready, as long as the caching mechanism is cluster friendly too, you could make it using mem-cached (http://memcached.org/) and one of it's java clients or one of the java caches. If you require absolute scaling then throw out the session all together and live with cookies or encoded urls, this way you can achieve truly stateless server side and you can add more servers without any sort of sticky sessions or session replication problems etc. - Ville Ps. for 99% of cases using as light user session as possible + pure java cache is the right way to go afaik, so consider sessionless + memcahced only if you plan on running the software with loads or servers. Jim O'Callaghan 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. > > -- View this message in context: http://old.nabble.com/Advice-on-Tapestry5-best-practise-for-user-session-data-tp27099574p27100214.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
