Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <1499435972506-19575.post@n4.nabble.com>
References: <1498645555365-19184.post@n4.nabble.com> <CABuYRcru=pWOQeEFz-XfAUvSKTi6i9k-xAPrkzVX4qS2qbFwUQ@mail.gmail.com>
 <1498686226432-19211.post@n4.nabble.com> <1499250326734-19480.post@n4.nabble.com>
 <CABuYRcpXKaWOncNXmXioGm5fCRDi7amBrc8Cq72Mqv0_zBgnrw@mail.gmail.com> <1499435972506-19575.post@n4.nabble.com>
From: Valentin Kulichenko <valentin.kulichenko@gmail.com>
Date: Fri, 7 Jul 2017 14:44:51 -0700
Message-ID: <CABuYRcrxDY4TvRFvCtQBbGpQq2oE6YMix+Q3JuMGYXPOkytdZQ@mail.gmail.com>
Subject: Re: It seems WebSession's removeAttribute does not support HttpSessionBindingListener
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a113f5dfe6c90e00553c1267b"
archived-at: Fri, 07 Jul 2017 21:45:34 -0000

--001a113f5dfe6c90e00553c1267b
Content-Type: text/plain; charset="UTF-8"

This will not work. WebSessionV2 does not reinvent the wheel, it provides
additional functionality. In particular, allows to use the same session in
a clustered environment.

Genuine session is local, so if you just rely on it, all session data will
be lost when server that holds this session fails. Your listeners will not
be invoked as well, BTW. That's exactly what we're trying to avoid by
introducing this feature.

However, I agree that there is an issue with expiration. It's currently
handled based on ExpiryPolicy, i.e., if maxInactiveInterval is set, session
will be removed from the cache. But looks like we do not invalidate the
genuine session, which is wrong.

I think we should add a CacheEntryListener that will listen to expirations
and handle all required post actions - invalidation of genuine session and
invoking the listeners.

-Val

On Fri, Jul 7, 2017 at 6:59 AM, yucigou <yuci.gou@gmail.com> wrote:

> Hi Val,
>
> The mechanism is similar to the implementation of invalidate() of the
> WebSessionV2 class. The {@link #invalidate()} action is delegated to the
> genuine session. Similarly, actions setAttribute(), removeAttribute(), and
> setMaxInactiveInterval() should be delegated to the genuine session. This
> way, the web container can do to the session whatever it promises to do,
> such as calling the HttpSessionBindingListener's valueUnbound callback
> function, etc.
>
> If you look at the HttpSession interface, this is the whole list of APIs
> concerned:
>
> * setAttribute()
> * removeAttribute()
> * setMaxInactiveInterval()
> * invalidate()
> * putValue()
>
> And putValue() has been covered by setAttribute() in WebSessionV2
>
> There are two main reasons that WebSessionV2 should delegate to the genuine
> session:
> 1. Avoid re-inventing the wheel. The web container has already implemented
> the related APIs.
> 2. WebSessionV2 is not visible to the web container. When the web container
> decides to expire the session, it will not reach the WebSessionV2
> implementation. And this is exactly where I had the problem in the first
> place.
>
> By the way, thanks for pointing out removing attributes, I've made another
> pull request on GitHub:
> https://github.com/apache/ignite/pull/2243
>
> Also I can't assign the ticket to myself because of lack of permission:
> https://issues.apache.org/jira/browse/IGNITE-5607
>
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/It-seems-WebSession-s-
> removeAttribute-does-not-support-HttpSessionBindingListener-
> tp19184p19575.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

--001a113f5dfe6c90e00553c1267b--