What is your Jira ID? I will add you as a contributor. -Val
On Fri, Jul 7, 2017 at 2:44 PM, Valentin Kulichenko < [email protected]> wrote: > 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 <[email protected]> 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-developer >> s.2346864.n4.nabble.com/It-seems-WebSession-s-removeAttri >> bute-does-not-support-HttpSessionBindingListener-tp19184p19575.html >> Sent from the Apache Ignite Developers mailing list archive at Nabble.com. >> > >
