myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Mathew" <jacobgmat...@gmail.com>
Subject Re: Thread safety for Orchestra access scope
Date Fri, 12 Dec 2008 01:22:19 GMT
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 <jacobgmathew@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 <jacobgmathew@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
>>
>
>

Mime
View raw message