Each request has its own component instances if the default state manager of myfaces is used (client & server state are handled equal). If a user is using a component binding and stores this component in a session or application scoped bean he definitely will have problems since this component instance will be shared across the requests. If a user uses a session or application scoped bean he must take care for synchronizing them.
I like Vesas solution since it is easy to implement and the existing application must not be changed. 2005/11/9, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > A second thought: > > There migth also be some important issues with the new sever-side state > saving. I'm not sure how it is implemented in detail. The state consists of > the component tree and the state. > Now if concurrent requests are processed for the same view, every request > should get a individual component tree otherwise fatal side effects would > occure within the components. > > Mathias can you clarify the way how the component tree is saved and restored > with the new implementation? > > > > > [EMAIL PROTECTED] schrieb am 09.11.2005 09:26:09: > > > You'll need to synchronize access to your session objects - there > > really is not much way around it. > > > > Alternative is to have everything client side, then you don't have any > > problems on the server. > > > > Except the performance, of course ;) > > > > regards, > > > > Martin > > > > On 11/9/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I've noticed that if I click multiple times on a component that does a > > > submit then quite often I get an exception generated in the server. > > > > > > The most obvious case for me is a table with a sortable header; if I > > > pretend to be impatient and click several times on the sort header then > > > usually I end up with an exception page. > > > > > > I believe the cause is that the browser has submitted several > concurrent > > > post requests to the server; multiple threads within the server then > try > > > to run the view at the same time, and as view components are not > > > threadsafe all sorts of nasty side-effects occur. An example of a > > > non-threadsafe component is a UIData with session scope; it's got only > > > one rowIndex, so multiple threads trying to iterate over the rows in > the > > > table is bound to result in something unpleasant. > > > > > > How do people handle this? I can't force my users to go on a training > > > course about waiting for a page to complete before clicking again. And > I > > > can't live with exception pages being rendered to them if they click > too > > > quick. > > > > > > Thanks, > > > > > > Simon > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > -- Mathias
