Short-lived vs long-lived sessions

[zcc39r]

Considering Repository and Session - Thread-safety + Long-running sessions :

Web applications, for example, often will obtain a Session for each incoming request, use that session to process the request, and then will close the session.

and

...ModeShape 3 sessions are thread-safe and can be used by multiple threads.

I have some questions:

1. What about ModeShape 4? Are it's sessions thread-safe too?

2. What are drawbacks of using long-lived sessions in Web application for regular repository operations (reading/writing nodes)? What if I'll map a Session onto HttpSession in order to minimize overhead of obtaining a Session for each subsequent request? Is it a viable technique?

[hchiorean]

1. What about ModeShape 4? Are it's sessions thread-safe too?

Yes, they are. ModeShape 4 is based on ModeShape 3 and does not change any of the core design/architecture. The only significant difference is in the query/indexing mechanism. However, to be able to successfully work with multiple threads against a single session it's vital that you configure Infinispan PESSIMISTIC locking with READ_COMMITTED isolation. See Configuration - ModeShape 4 - Project Documentation Editor.

2. What are drawbacks of using long-lived sessions in Web application for regular repository operations (reading/writing nodes)? What if I'll map a Session onto HttpSession in order to minimize overhead of obtaining a Session for each subsequent request? Is it a viable technique?

You should avoid long lived sessions mainly for performance reasons:

• memory - sessions hold on to lots of objects internally which can only be released once the session is closed
• throughput - if long lived session are subject to concurrency - i.e. multiple threads making use of the same session, you will get a lot of lock contention which can potentially slow your application

In the context of a web application, the general pattern IMO is to create a new session at the beginning of each request and close it once that request has finished (either successfully or not).

[wesssel]

As a tip: to minimize overhead make sure the authentication backend is fast, this is the biggest bottleneck in getting sessions. ModeShape 4.3 supports using WildFly's caching mechanism which I would highly recommend if you are using Modeshape in WF. For example, we were only able to get 6 sessions per second using an Active Directory LDAP for session authentication without caching. With simple file based authentication we were able to get 70 sessions / second, without caching.

[zcc39r]

However, to be able to successfully work with multiple threads against a single session it's vital that you configure Infinispan PESSIMISTIC locking with READ_COMMITTED isolation.

Having configured Infinispan with locking and isolation mentioned above, I encounter an issue with session isolation. Long-running observation session's listener succesfully receives NODE_ADDED event for node created in another session but unable to get this node (PathNotFoundException). It affects not only the observation session but every session opened before the node creator session.

[hchiorean]

as long as the node hasn't been removed elsewhere, I don't see a reason why after a NODE_ADDED event is emitted, it should not be accessible from other sessions (not including things like ACL visibility etc).

If you create a test case which shows this problem, feel free to log a JIRA and I'll check if the problem still occurs with ModeShape 5 or not.