Re: Thread safety for Orchestra access scope
Thank you for the response. I had read the multi-window topic in the documentation earlier (and also remember thinking it was outstandingly good, I thank the author). As far as how bad it can get if a user can (maliciously) concurrently access non thread safe code even within their own session, I can think of many contrived examples where the damage can be arbitrarily bad. The first that came to mind is the following list of commands. login(root) runRestrictedCommandsForSetup() logout() login(currentUser) run(inputedUserCommands) logout() It's easy to see that when run concurrently, there is a possibility that inputedUserCommands might run as root, which can be arbitrarily bad. But there are less contrived examples too. A transaction object might end up getting shared for multiple threads, and then whole bag of race condition problems (simultaneous withdrawal from banks, etc.) are in the picture. I understand what you say about sharing conversationContexts across windows. I would rather the situation never happens. But unfortunately, as acknowledged in the documentation, it requires the co-operation of the user, which is not something I am willing to bank on. In fact, it would seem like the most natural ways for creating new tabs (right click and select open in new tab, copying the link) causes the context to be shared. So I do have to make sure that my application will at least be sound when this happens, if not predictable to the user. To me, this means I need to handle 1. Concurrent access to conversation scoped beans 2. Dirty views - i.e. when handling a request I cannot assume that the bean was in the same state as when the page that sourced this request was rendered - this subsumes your example of the deleted conversation. It looks like I don't have to worry about 1 though because of the locking on the context (except for the border case, but thats too hard to deal with, I'm going to drop it, unless Orchestra is updated). And for 2 - well, I'm still investigating how I am going to deal with that on a general basis... -Jacob On Thu, Dec 11, 2008 at 11:35 PM, Simon Kitching skitch...@apache.orgwrote: 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
Re: Configure ConversationContext timeout in Orchestra
What is the motivation for setting a timeout for the context? Ultimately you are interested in the deletion of beans in a conversation right? Can you not achieve that by setting the timeouts on the conversations directly? Every bean in a conversationContext is inside a conversation... -Jacob On Fri, Dec 12, 2008 at 11:40 AM, Steve Ronderos steve.ronde...@ni.comwrote: Hello Users, I've looked around for documentation on how to override the 30 minute time out default that is set for ConversationContext in Orchestra. I'm able to configure the Conversation timeout fine for both conversation.access and conversation.manual, but I have been unable to find the configuration for ConversationContexts. Does anyone know how I can configure this setting? Thanks, Steve Ronderos
Thread safety for Orchestra access scope
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
Re: Thread safety for Orchestra access scope
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.comwrote: 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
Re: Thread safety for Orchestra access scope
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.comwrote: 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.comwrote: 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
Reference to documentation for implementing functions to be used in EL
I'm looking for documentation on implementing functions that can be used in EL in jsf pages. Maybe I'm missing something, but the best info I can find is that the a FunctionMapper object is used to resolve functions that show up in EL. But how can I define my own FunctionMapper? how do I set it? Can the default FunctionMapper be configured through an config file? I can't seem to find any info on this. Any reference will be much appreciated. -Jacob
