Nathan Bubna wrote:
> Gabe said:
>
>>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?
>>
>
> it is not the situation that is far fetched, it is the possibility of the
> situation resulting in an error. you see, there still is only one session
> for this user, and it is in that session that we store the tools. all
> should we need to do is synchronize the initialization/storing of those
> tools on the session object, and there should be no problem. further, even
> if we do not synchronize that process, it would have to be a very poor
> design if all three of those "virtually concurrent" initial requests would
> initialize the session tool(s) with different data! if the site and tools
> are properly designed, the worse that would happen is that the session
> tool(s) would be initialized and stored identically three times, and
> subsequent requests would still find only one set of those session tool(s)
> in the user's session attributes.
I didn't think about tool initializiation as the primary problematic
situation. Much more likely are threading problems if a tools uses
read-write instance variables. Synchorniszation wouldn't help in all
such cases.
Gabe
>
> Nathan Bubna
> [EMAIL PROTECTED]
>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
