Reading your ticket against GF I think GF behaves correctly. But I wonder
why Tomcat/Jetty don't do this.

So here is what happens:

org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create)
{
SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId());
}
if (entry != null)
 {
synchronized (entry)
{
setSessionAttribute(getAttributeName(), entry);
 }
}
return entry;
}

I think the correct code should be:

private SessionEntry getSessionEntry(boolean create)
{
SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId());
setSessionAttribute(getAttributeName(), entry);
 }
return entry;
}
I.e. set the SessionEntry as an attribute in the http session only when it
is created.

Because with the current code we call
"setSessionAttribute(getAttributeName(), entry);" even with already
existing entries and this leads to notifications
to HttpSessionBindingListener - new value is bound, old value is removed.

I guess Tomcat and Jetty optimize this by doing identity check.

Another solution would be SessionEntry to implement HttpSessionListener
instead and check the sessionId of the unbound session against its own one
and clean the data store if they are equal.





On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors <p...@bors.ws> wrote:

> Created https://java.net/jira/browse/GLASSFISH-20828
> "HttpSessionBindingListener.valueUnbound() is always called right after
> valueBound() with a null HttpSessionBindingEvent.getValue()"
>
> Let's see what becomes of this...
>
>
>
> -----
> ~ Thank you,
>     p...@bors.ws
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661582.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to