Hi Simon, again, my comments are inline... (Thx for the answers.. they are really helping me in increasing my knowledge about this topic.)
> As I mentioned in an earlier email, for server-side state saving myfaces > (and Sun SI) maintain a cache of old component trees. Well, they have to, otherwise the component tree cannot be restored. In my case they maintain exactly one view, I've set the number of stored views to 1. > For server-side state, if they have the same session cookie then yes I > would expect both requests to use the same component tree. Well, > actually the component tree is serialized into the http session then > deserialized, so the two requests will be working with separate > identical copies of the component tree. Well... I am talking about the following use case: You are starting one browser window, and then forking this window, so that the same session is used... this Is a common use case IMO, at least I am using this frequently,... If it's true, that JSF restores the same component tree for two different requests, just because they have the same Session.... that's..... HORRIBLE.. ;). I can't believe that... Problems would not only occur if you are using Session beans.... there are much more problems. Just imagine the following: You are having a t:dataTable, which uses automatic sorting... The information which column is sorted and wheter ascending or descending sorting is used, is stored in the component... (If you don't specify a binding for this)... So... just think of a user who sorts the dataTable T1 in the browser window W1 in another way than the same table T1 on another browser window W2, ... then the user returns to W1 and does some other things, but still stays on the same page... BANG... the table is sorted in the same way as on W2... That's not good :D. Well.... I am not able to attach any files to my mail, so here is the link to the specification: http://java.sun.com/javaee/javaserverfaces/download.html Dominik
