Nathan Bubna wrote: > Gabe said: > >>Thread-safety is an issue for session scoped tools as well. The >> > requirements > >>are somewhat different thought. Think about a web client loading a >> > frame-set > >>page. It can easily generate multiple virtually concurrent requests that >>are all within the same session. >> > > bit of stretch, don't you think? i suppose it's remotely possible that this > could cause a problem. but if such a situation did cause a problem, i would > lean heavily toward faulting very poor design of the tool and site, rather > than going to great lengths to prevent this. it's hard for me at least > (even if no one else) to see this as a reasonable concern. IMO, the only > scope where thread safety is a reasonable concern (barring any inappropriate > use of static members, of course) is application scope.
I don't think it is far-fetched at all. Think of the following case: Browser loads frameset file with three subframes. This will result in three virtually concurrent requests to the server. All three requests are within the same session because they come from the same client. Three different server threads will assigned to handle these requests. It is quite likely that the execution of the these three threads is overlapping in time. Now, if multiple threads access the same session- scoped tool, thread-safety is clearly a requirement for this tool. Why do you think this is far fetched? Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
