myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Thread safety for Orchestra access scope
Date Fri, 12 Dec 2008 07:35:25 GMT
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

See here for more details:

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.


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

View raw message