Wizard SSOs are a typical example of the temporary state I mentioned. No one else should be able to write to it and thus you don't need guards against concurrent writes. Especially not, since you validate the business objects before comitting them. But still it could be a neat idea in some circumstances to save intermediate stages of the wizard to a datastore, so that the user can later log in again and continue where he left off without the need for cookies (which can be disabled on client side for example) and even when his session expired.
2009/7/15 <p.stavrini...@albourne.com> > I don't agree with your implication that a user should only be reading from > the session, one example I am using is a wizard that uses an SSO over a few > pages, once all steps are completed only then is the data written to the > database and the SSO is discarded, using an SSO for this is natural choice > imho, but even that is beside the point Otto, as I have mentioned already I > don't think its a big deal since it is unlikely (although not impossible) > that you will have concurrency problems accessing the HttpSession, the > original issue in question is the multiple threads modifying persistent > data, a 'get -> modify -> set' pattern, which then has the potential to be > wrong when re-reading the value. > > Peter > > > >
