On 26/11/2014 06:39, Yannick Majoros wrote:
>
> Hello,
>
> A couple of weeks ago, I wrote this message in the Java EE users mailing
> list. Bill Shannon suggested that it would be interesting to post it
> here. I'm very interested in your opinions on that.
>
> While trying to find out if a server is allowed to create sessions for
> REST services, I didn't find anything in Java EE specifications.
>
> Some background information: we did some performance investigation of
> some web services, which don't create sessions by themselves but rely on
> Java EE authentication.
>
> It seems that Weblogic creates sessions for that, and even replicates
> them in our cluster environment.
Then raise a bug with Weblogic support.
> While I think this is an implementation choice to handle authentication,
> I really think a word of caution should be found in the specs.
No objection to that.
> As you
> can guess, this makes it difficult to create stateless, scalable
> web services. Our workaround right now is to specify 1-minute sessions
> and to disable replication for this application. Shouldn't there be
> a standard way to say that you want to have a stateless application?
There already is. Don't create a session.
Containers that are automatically creating sessions purely to cache the
result of the authentication process should be providing an option to
disable that.
I think it makes sense for some wording to be added to section 13.6 of
the Servlet spec to:
- make clearer which authentication mechanisms (FORM) are expected to
create HTTP sessions (I assume everyone is creating HTTP sessions
to handle FORM auth)
- highlight the pros/cons of creating sessions rather than
authenticating on every request
- recommend that containers that create sessions purely to cache the
results of authentication provide a mechanism to disable that
We could go further and add an element to web.xml to control whether or
not a session may be created purely to cache the result of the
authentication. No objections to that either.
Mark