Nathan said:
> Gabe said:
> > 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.
>
> No, not at all.  Mutable instance variables are not a problem for session
> tools.  Each separate browser that connects to a servlet that uses
sessions
> gets its own unique session.  This session can be created upon initial
> request or upon some sort of login action, and it will remain associated
> with _only_ that browser until it either times out or is invalidated by a
> logout action of sorts.  Even if the same user opens the site in a new
> browser (not just a new window of the same browser instance), that browser
> will get a new session of its own.  So even though multiple requests
> (threads) may be executing for the same session, as in the frameset
> situation you propose (and i'd venture to say that that is a highly
uncommon
> situation), all of those requests will be using the same session object
and
> therefore, their own unique set of session tool instances.  Requests made
> for other sessions will have their own instances of those tools.  So i
> repeat again, the only scope-placement in the servlet environment where
> thread-safety is a legitimate concern is the application scope.

eh, i should rephrase... that's not completely true.  i suppose it is
theoretically possible for multiple virtually simultaneous requests by the
same session to happen even after initialization.  but this is an even less
common situation (how many applications really load multiple framesets
during a session?).  and once again, if such a situation causes a problem, i
fault poor design of the tool and site, not lack of enforcement by a toolbox
manager.  in other words, i still don't consider this a legitimate concern
for us here.  if you personally have a tool with this issue and you don't
want to change your API or templates, just synchronize the problematic
method(s).

Nathan Bubna
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to