Session namespaces support

[mkopylec]

trafficstars

Hi, what do you think about adding namespaces support to Spring Session? I have created such an impelmentation in data-couchbase support: https://github.com/spring-projects/spring-session/pull/468 @rwinch points out that there should not be a support for namespaces in the PR so let's discuss it here.

The idea is to have a global session namespace (that's how Spring Session is implemented now) and an additional, optional appilication namespaces:

• application namespace - attributes are visible only to instances of the same web application within a distributed system
• global namespace - attributes are visible to all instances of all web applications within a distributed system

By default namespaces support could be turned off somehow.

Having namespaces pros (in my opinion):

1. Session data in a large distributed system (aspecially in microservices architecture) can be pretty big. Having application and global namespaces reduces the amount of data to read every HttpSession.getSession() invocation. You can gain a significant performance boost using session namespaces.
2. With namespaces multiple different apps/services in the system can set or get a session attribute of the same name without conflicting each other.

Here you can see how namespaces work in data-couchbase PR.

[rwinch]

@mkopylec Thanks for creating the ticket. What is the reasoning for having multiple namespaces?

[mkopylec]

I've already written it in my first post, see 1. and 2.

[rwinch]

@mkopylec This isn't very clear to me. Can you provide a more concrete example. Possibly providing actual sample values of how this feature would be used?

I should add that:

. It's also not clear to me why this feature solves performance problems. Can you elaborate?

. Multiple applications can already use something like redisNamespace to avoid Sessions from one application being used by another.

[mkopylec]

Ok.

1. Performance aspect: Let's say we have a distributed system containing 20 services (web applications). All of them need to access HTTP session. You access the system using the same domain, for example: domainname.com so the session id is the same for all services. Every service in the system will likely operate on its own set of session attributes. Therefore those attributes don't have to be known to other services. Spring Session reads whole session data every time HttpSession.getSession() is invoked. In one request there can be multiple calls to HttpSession.getSession(). In that case every service in the system will read session data that it doesn't need to access, and this operation will be very frequent. This will cause significant impact on response times. With namespaces support there is no need to read the whole session data every HttpSession.getSession(), the services will only read session data belonging to their application namespace.
2. Session data conflicts: Redis namespaces are ok, but they are only for redis. Other spring-data session storages doesn't support them. I created this ticket to sugest adding (optional) namespaces support to all storages. We can for example add new session repository interface that contains methods like: getSession(String namespace), saveSession(String namespace, Session session) etc. Than every spring-data session implementation could implement it by its own way.

[mkopylec]

I just have run into another problem that namespaces could solve in my job :)

Simultaneous session data writes:

Lets analize the following situation: Webapp A and B are accessed behind the same domain name, for example: http://example.com

1. Webapp A reads session data
2. Webapp B reads session data
3. Webapp A sets attribute X
4. Webapp B sets attribute Y
5. Webapp A commits the session
6. Webapp B commits the session
7. Webapp A reads session data
8. Webapp A gets attribute X and is it gone

This is because webapp B has overwritten webaap A session commit. Using namespaces this situation is impossible to occur, becuase every webapp reads and writes its own data to session.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.