Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345702

Summary:

Refactor SessionSingletonBase

Product:

[RT] RAP

Reporter:

Rüdiger Herrmann <ruediger.herrmann>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

enhancement

Priority:

Version:

unspecified

Target Milestone:

1.5 M1

Hardware:

All

OS:

All

Whiteboard:

Bug Depends on:

345395

Bug Blocks:

344331

Attachments:

Description	Flags
Proposed fix	none
Proposed fix #2	none
Proposed fix #3	none
Performance comparison before/after patch #3	none

Description Rüdiger Herrmann

2011-05-13 04:56:55 EDT

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.

Comment 1 Rüdiger Herrmann

2011-05-13 11:43:30 EDT

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().

Comment 2 Rüdiger Herrmann

2011-05-14 05:06:12 EDT

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.

Comment 3 Rüdiger Herrmann

2011-05-14 11:49:08 EDT

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.

Comment 4 Rüdiger Herrmann

2011-05-16 04:56:30 EDT

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

Comment 5 Rüdiger Herrmann

2011-05-18 08:28:48 EDT

Applied patch #3 to CVS HEAD.