> I am curious why the entire engine is placed in session. > > I understand that much of it is transient, but something just doesn't make > sense to me. I've been wondering about this for a while, but let me just > make sure I have it straight (this is from memory, so please correct if I'm > way off): > > - the servlet holds an engine pool > - each engine has a page pool (not sure why the page pool wouldn't just be > in the servlet, not sure why you need so many page pools (e.g. if there is > more than one engine in the engine pool))
Nope, the engine has a transient reference to a shared page pool, which is stored in the ServletContext and shared by all engines. > - engines are returned to the pool unless a session has been created (a > visit or page recorder is used), whereupon that engine is added to session > - when the session invalidates, the engine is returned to the pool (or just > gets garbage collected if the user "disappears", not sure if this will > happen unless engine pool uses weak refs) An engine attached to a HttpSession doesn't go back into the pool. When the HttpSession times out, the engine is discarded (to the garbage collector). > > Just curious as to the design principles involved. Wondering if this is > just a side effect of an initial design decision that has stuck around. More or less. I've definately given some thought to other options; for example, storing each page's persistent state in a seperate HttpSession attribute. I store the whole engine because the relationship between the engine and visit is tricky (originally, there was no division --- you had a single application object; the split is primarily to allow for stateless applications). Take the Vlib ... the Vlib Visit holds a reference back to its engine, because the engine is where all the JNDI lookups to EJBs occur. Why? Because those lookups occur even before the visit is created. Putting aside storing page state, we could develop a more complicated relationship between the engine and the visit ... where the engine 'hooks up' to the visit and vice-versa for the duration of the request. However, what I like about the current design is that the Visit doesn't need to implemnt any interface except, optionally, Serializable. The cost of this flexibility is few hundred bytes to store the engine and the visit (and the page state) together. > > -C > > > Protect yourself against identity theft with Equifax Credit Watch. Visit > http://www.creditalert.equifax.com. > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended recipient, please > refrain from any disclosure, copying, distribution or use of this > information and note that such actions are prohibited. If you have > received this transmission in error, please notify by e-mail > [EMAIL PROTECTED] > > > _________________________________________________________ ______ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm? source=osdntextlink > > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry- developer -- [EMAIL PROTECTED] http://tapestry.sf.net > I am curious why the entire engine is placed in session. > > I understand that much of it is transient, but something just doesn't make > sense to me. I've been wondering about this for a while, but let me just > make sure I have it straight (this is from memory, so please correct if I'm > way off): > > - the servlet holds an engine pool > - each engine has a page pool (not sure why the page pool wouldn't just be > in the servlet, not sure why you need so many page pools (e.g. if there is > more than one engine in the engine pool)) > - engines are returned to the pool unless a session has been created (a > visit or page recorder is used), whereupon that engine is added to session > - when the session invalidates, the engine is returned to the pool (or just > gets garbage collected if the user "disappears", not sure if this will > happen unless engine pool uses weak refs) > > Just curious as to the design principles involved. Wondering if this is > just a side effect of an initial design decision that has stuck around. > > -C > > > Protect yourself against identity theft with Equifax Credit Watch. Visit > http://www.creditalert.equifax.com. > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended recipient, please > refrain from any disclosure, copying, distribution or use of this > information and note that such actions are prohibited. If you have > received this transmission in error, please notify by e-mail > [EMAIL PROTECTED] > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
