Community
Participate
Working Groups
The current implementation of SessionSingletonBase consists only of static methods and holds all its state in session attributes. The implementation could benefit from having an (internal) instance that holds all the state. This instance in tourn would be stored in the session. The readability of the code would benefit from this change and even performance improvements might be possible as the the number of calls to HttpSession#getAttribute() would be reduced. However as the changes are in a performance sensitive area, it should be verified that at least they do not cause a degrade in performance.
Created attachment 195602 [details] Proposed fix Introduces a SingletonManager that actually maintains the session singletons. There exists one instance of a SingletonManager per session, which is accessible from the 'outside' via SessionSingletonBase#getInstance().
Created attachment 195640 [details] Proposed fix #2 Same as patch #1, plus a test case to ensure that creating singletons interlaced from different threads does not load to a dead lock.
Created attachment 195645 [details] Proposed fix #3 Same as patch #2, plus SingletonManager#install(ISessionStore) now throws an exception if a SingletonManager was already installed into the given session store.
Created attachment 195697 [details] Performance comparison before/after patch #3 The attached method is meant to be pasted in an arbitrary test case. It simulates 300 concurrent sessions where each session iterates five times over a loop that retrieves (and creates on the first invocation) eight session singleton instances. The duration is measured with System#currentTimeMillis. I ran the code ten times, the average duration is: * before the change: 252.6 ms * after the change: 167.6 ms
Applied patch #3 to CVS HEAD.
