Hi Jacob, Thanks very much for your comments.
I don't believe that "guessing the conversationcontextid" is significant, because the id is per-session. As you point out, someone *can* maliciously try to guess the value, thereby creating race conditions for data *in their own session*. But I don't see any way to expand that to corrupt data in other sessions or create a denial-of-service for anyone else. If you can think of a way someone can use this to affect anyone other than themself, please let me know! Note that having two tabs or windows with the same conversationContextId is a bad idea; separate windows should have separate conversationContextId values. The per-context locking is really just to ensure that things like users double-clicking on a submit button don't cause races. If the user can select the same view in two different windows, and you use the same conversationContextId (or a session-scoped backing bean) then the two windows will interact in unpleasant ways. Having different conversationContextIds ensures that the backing bean instance is *different* for the two windows, so no nasty interactions occur. Note also that if you want multiple windows, you really should select client-side-state-saving. See here for more details: http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html That's the reason there isn't much documentation on the "conversation locking" feature of Orchestra; apps should use different conversationContextIds for different windows. The locking is just a safety measure for some odd corner cases, not a major user feature. Regards, Simon Jacob Mathew schrieb: > It should be noted that the border case where the first request > creates a new conversationcontext is not completely sound. In this > scenario, no lock is acquired "because nothing else can refer to that > newly created [conversationcontext] id until the response for this > request has been sent back to the client browser". This is not true. > The second request can simply guess the conversationcontext id which > is a simple alphanumeric increment. Admittedly not a situation likely > to happen unless someone was explicitly trying to break the > application, but a legitimate hole nonetheless. > > -Jacob > > On Thu, Dec 11, 2008 at 4:14 PM, Jacob Mathew <jacobgmat...@gmail.com > <mailto:jacobgmat...@gmail.com>> wrote: > > The source code for Orchestra provided the answer I was looking > for. It looks like a lock is acquired on the conversationcontext > object corresponding to the request before accessing any of the > beans inside of a conversation. So the execution of two requests > in the same conversationcontext will not happen concurrently, > which mean beans in a conversation (access) scope do no, in > general, need to be thread safe. > > Explicit documentation of this will probably be useful. > > -Jacob > > > On Thu, Dec 11, 2008 at 10:52 AM, Jacob Mathew > <jacobgmat...@gmail.com <mailto:jacobgmat...@gmail.com>> wrote: > > I was under the impression that beans that I set up with > access scope will need to be thread safe because I could have > a user open two tabs (with the same conversation context) and > submit to the same page simultaneously (or double submit on > the same tab). > > But I was running some tests and it seems like something in > the framework is forcing accesses to my beans to be executed > in sequence rather than simultaneously. Specifically I set it > up so I had the first request stuck at a breakpoint and > submitted a second request (that does not hit the breakpoint), > but I found that *both* requests are stuck until I resume the > thread stuck at the breakpoint. > > Any insights? > > -Jacob Mathew > > > -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
