Back Forum Reply New

session management / command backing object race conditions?

Sorry to trouble you all, but I had a bit of trouble searching for an answer to this question, so I was wondering if anyone had any information to chip in.

My current understanding of Spring is that, similar to struts and other frameworks, information stored in the session is mutable and can be altered by other windows (for instance, if you hit ctrl + n to bring up a new window).  I'm in a situation where I want to fork off a few new windows for some reporting purposes.  Each one of those windows will get sent different information, but it will all be going through the same code.  I've heard that command backing objects suffer from the same problem, but I'm unable to verify this.  How can I avoid each window altering its siblings, or printing out their information instead of their own?  It seems like a classic race condition problem that I'm sure has quite a well documented solution, but unfortunately google is failing me.

Thanks in advance for any light you can shed on this!

Hi James,

As with most Web Frameworks, including Spring MVC, there is only place you can store information, in the session. The request is just like its name says, its a place where information is stored during the lifetime of the request, which is very short as once the information is returned to the user the information is forgotten about.

The session on the other hand is very interesting as it the concept of it is based around ids which are stored in cookies on your browser. This information is open to modification by any window and any request, so if you are storing information which you only want edited by one window (maybe a shopping cart style workflow) then the session is not the best place for it. Although the Spring team are looking at 'conversation' data (window specific) for MVC, your best bet at the moment is to have a look at Spring Web Flow, which is great in itself as it gives you a hoard of other benefits.

If you are just wanting to pass information from the browser to the server in form data then the request is more than fine as each window will spawn its own request.

I hope this helps. Have a read of the Spring MVC and Workflow reference docs as this should help you understand the workflow which takes place when a page is requested by the browser.

Josh
¥
Back Forum Reply New