Hi,
On Tue, Mar 24, 2015 at 8:04 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> This concept of stateful and stateless ness is referring to the concurrent
> processing of multi-state authentication dialogs;
> where the module must be able to process each incoming request against the
> proper state for the dialog of which the
> request is a part. Foy example a completely stateless module (in this
> regard), might keep all such state in cookies, so
> that it can easily determine the state in which the current request is to
> be processed. Another more stateful module, might
> store authentication dialog state in a session, which it would gain access
> to via a session cookie.
>
Thanks for the clarification. So, if I understand correctly it's not about
instance variables of the server auth module, is it?
The text sounded quite similar to that of a Servlet (e.g. HttpServlet):
"Servlets typically run on multithreaded servers, so be aware that a
servlet must handle concurrent requests and be careful to synchronize
access to shared resources. Shared resources include in-memory data such as
instance or class variables and external objects such as files, database
connections, and network connections"
In case of Servlets it's well known that a single instance of a Servlet
services multiple clients (threads) and therefor instance variables have to
be thread-safe.
But in the case of a server auth module it's not suggested that a single
class instance of that should be reused for multiple requests, right?
I'm still doubting a little whether that is or is not the case because of
this:
Once an authentication context is acquired, it may be reused to process
> subsequent requests of the application for which an equivalent
> authentication context identifier, Subject, and properties Map (as used in
> the getAuthContext) applies. Runtimes that wish to be dynamic with respect
> to changes in context configuration should call getAuthContext for every
> request.
> FWIW, this wording was chosen to make it possible minimize the performance
> impact of the 196 spi calls.
So an authentication context may be reused, but then the runtime that does
this reusing somehow has to pass the new CallbackHandler instance in for a
specific request and make sure that same authentication context instance is
not used for concurrent requests?
Or is the CallbackHandler supposed to be thread-safe and reusable itself by
multiple (concurrent or not) requests?
Kind regards,
Arjan Tijms
> The intent of this area of
> the spec being that a module author must recognize that the module may be
> involved in the simultaneous processing of
> multiple authentication dialogs, and the module needs to be able to
> diambiguate the dialogs any any related state kept within
> the module (e.g. a saved initial request that will be redirected to when
> authentication completes)
>
> HTH, and please continue the discussion if need be,
>
> Ron
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>