>>> Did we dissect a case of serving two or more connections
>>> simultaneously? Even on a single machine there is a possibility of
>>> executing 2 or more simultaneous requests from the same client.
>>>
>>> What's the proper thing to do when the first connection changes the
>>> session id while the second connection offers an older session-id and
>>> has yet to obtain the HttpSession using old session-id? (old
>>> session-id is an id prior to change)
>>>
>>> I am not exactly sure yet… I think a session should be made available
>>> by an old session-id to a connection that opened before session-id
>>> changes. If so… how far back do we go? i.e. how many previously used
>>> Ids for the same session remain valid for fetching the session?
>>> (connection priority rule observed)
>>
>> -1. That would defeat the session fixation protection - the primary
>> reason for this feature.
As long as we spell out the implications in the spec clearly…
> Yes, I agree there would be almost no point bothering with the feature.
>
> Concurrency issues seem to exist with most session operations, especially its creation.
Before, we did not have long lasting operations such as async.
Alex
>
> Rémy