Much obliged. On 16 August 2012 15:21, Lenny Primak <lpri...@hope.nyc.ny.us> wrote:
> Comments interspersed... > > > > On Aug 16, 2012, at 2:03 PM, Michael Prescott < > michael.r.presc...@gmail.com> wrote: > > > Just want to check my understanding on a few matters. > > > > Pages and components are pooled and cleaned up between requests, so it's > > fine to use fields for storage during request procesing (e.g. loop > > variables), or as gateways to session state (e.g. fields marked with > > @SessionState). > > Not quite. Pages and components are singletons, but the fields inside > pages are re-written to be thread local so they don't trash each other and > get cleaned up after every request unless @Persisted. > > > Services (including dispatchers) are generally singletons, however, so > > fields annotated with @SessionState aren't legit: state would leak > between > > concurrent requests. > > Yes. @sessionstate is only meant to be used in pages and components. It > does nothing in services. > > > If you need to access session state from a service, you need to use an > > injected ApplicationStateManager from within the methods. > > > > (@SessionState fields within a per-thread service is theoretically > > sensible, but it's not supported.) > Yes > > > For Tapestry-hibernate, it's okay to @Inject a hibernate session into a > > service, however, because the session implementation you get is a service > > defined with per-thread scope, so you don't get bleed between requests. > Yes > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
