But in the same thread as the code calling a getter? That makes no
sense to me (and leads to all kinds of problems). I don't think this
ever happened with 3.1.1. I'll try to write a small test app to try
this with 3.1.1.
Once again, this:
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html#getAttribute(java.lang.String)
If I'm calling getAttribute and the session is no longer valid, I
should get an exception back.
Bobby
On Fri, Aug 10, 2012 at 8:01 PM, Shing Wai Chan
<shing.wai.chan_at_oracle.com> wrote:
> If the session is expired, then we should expect it would be cleanup and
> hence the invocation of HttpSessionListener#sessionDestroyed at any time.
>
>
> On 8/10/12 2:38 PM, Bobby Bissett wrote:
>>
>> On Fri, Aug 10, 2012 at 5:23 PM, Shing Wai Chan
>> <shing.wai.chan_at_oracle.com> wrote:
>>>
>>> In general, the expired session is cleaned up by a background thread.
>>> But if it is used before cleaning up, then it will be cleaned up while
>>> accessing.
>>> From description below, it is the latter case here.
>>
>> Thanks, that makes perfect sense. But in terms of what the calling
>> code sees, should this happen? According to
>>
>> http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html#getAttribute(java.lang.String)
>> I would expect it to throw an IllegalStateException. There's nothing
>> in the JavaDoc to indicate that calling this method could result in a
>> SessionListener being called. As you can understand, that leads to an
>> unexpected (and hard to test) edge case for handling concurrent access
>> to a session object.
>>
>> Thanks,
>> Bobby
>
>