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>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>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 >> > >
