> If you subclassed the Session class and your attributes are properties > of the subclass.
Yes I did. > But you are required to call session.dirty() only if your pages are > stateless and your application is deployed on cluster. Why the session.dirty is called by the framework after modifying feedback messages. I would expect feedback messages to be associated only with stateful pages. So .dirty should be called in stateful situations too? Darn. This is not fell like a very clean design, does it? Practically, the session is dirty after every request. I cannot imagine otherwise. Does this mean that session is NOT the place to store state? The problem with storing the state in a page is that when the page is re-instantiated on a reload the instance variables are reset. Storing the variables into the session overcomes this problem, but if I always have to call .dirty my code gets cluttered and brittle - how can I test that my app is now cluster-safe? Ofcourse I could wrap all my state variables in a proxy object which handles the dirty automatically, but this seems like an overkill. I hope this was just a misunderstanding :) ** Martin 2008/5/3 Johan Compagner <[EMAIL PROTECTED]>: > Nop thats the best thing todo > > > > On 5/3/08, Michael Allan <[EMAIL PROTECTED]> wrote: > > Matej Knopp wrote: > > > Martin Makundi wrote: > > > > > > > > Let's say I have some variables in my session. If these variables > > > > change, do I have to call session.dirty? > > > > > > If you subclassed the Session class and your attributes are properties > > > of the subclass. > > > > > > But you are required to call session.dirty() only if your pages are > > > stateless and your application is deployed on cluster. > > > > Just to cover all eventualities, Matej (in case we later move to a > > cluster) is there any harm in *always* calling session.dirty(), when a > > Session field changes value? > > > > -- > > Michael Allan > > > > Toronto, 647-436-4521 > > http://zelea.com/ > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
