Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Session beans synchronization  RSS feed

 
Yasir Bajwa
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi. New to JSF, hoping for some guidance here

With a session scope managed-bean, does the JSF Framework 'lock' the bean for the duration of a request? If not, what would prevent a 2nd request coming in an overwriting the session data mid-way through the lifecycle of the first request? e.g. if user has two windows open for the same session/page and submits from both windows.

Thank you
 
a
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
it won't be "locked" (therefore I don't store data that often vary in sessionscope).
And if something has to be locked, then it should be the accessed data in sessionscope instead of the bean itself.
I think you could solve this programmatically if you have to "take care" of users who open two tabs and submit different data within the same form.

Cu
Alex
 
Yasir Bajwa
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is really problematic, as a big part of the design of JSF seemed to be protecting model integrity.

There must be some failsafe built-in to the framework to prevent users from corrupting model integrity via multiple tabs/windows?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't actually seen anything written on the topic, and YMMV depending on what JEE container you're using, however I'd always taken it on faith that for a given JEE user session the request/response cycle was atomic. That is, a second request wouldn't be passed to the app for that session ID until the first request was completed.

Although on reflection, that might actually be a Bad Thing, since a really evil person could probably find a use for the extra flexibility that totally unsynchronized access affords.

An easy test would be to set up a session object with a setter that went into a 10-second sleep, hit the app from 2 different windows, then check to see if the second hit hit changed the session property while the first one was sleeping.

If you encounter conflicts, you can make all or part of the session object be a synchronized object, or pass off to some sort of synchronized object such as an EJB.

Let us know what you find out!
[ June 18, 2007: Message edited by: Tim Holloway ]
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!