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

Bug 347478

Summary: Buffering ApplicationContext in SessionStore conflicts with serializable sessions
Product: [RT] RAP Reporter: Rüdiger Herrmann <ruediger.herrmann>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: fr.appel
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 342407    

Description Rüdiger Herrmann CLA 2011-05-27 11:55:21 EDT 
The 'current' ApplicationContext can be obtained from the ServiceContext. The current implementation uses of buffers the application context as an attribute in the session store (see ServiceContext#bufferApplicationContextInSession()). This causes a NotSerializableException if the servlet container tries to serialize the session.
As the ApplicationContext does not actually belong to the session, it must not be serialized when the session is serialized by the servlet container.

The current workaround is to wrap the ApplicationContext into a TransientValue wrapper class that implements Serializable but holds the ApplicationContext in a transient field.

Ideally we would not buffer the ApplicationContext in the SessionStore at all. 
The ApplicationContext that is buffered in the SessionStore is only accessed once per request. Subsequent calls to ServiceContext#getApplicationContext() use the value that is buffered in the applicationContext field. Is it really a worthwhile performance gain if the ApplicationContext is buffered in the SessionStore?
Comment 1 Frank Appel CLA 2011-05-27 13:36:53 EDT 
(In reply to comment #0)
> Ideally we would not buffer the ApplicationContext in the SessionStore at all. 
> The ApplicationContext that is buffered in the SessionStore is only accessed
> once per request. Subsequent calls to ServiceContext#getApplicationContext()
> use the value that is buffered in the applicationContext field. Is it really a
> worthwhile performance gain if the ApplicationContext is buffered in the
> SessionStore?

Unfortunately it turned out that receiving the ApplicationContext from the underlying ServletContext is expensive (see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=337787#c5). At the moment I cannot think of a better solution :-(
Comment 2 Frank Appel CLA 2011-05-27 13:40:11 EDT 
(In reply to comment #1) 
> Unfortunately it turned out that receiving the ApplicationContext from the
> underlying ServletContext is expensive (see:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=337787#c5). At the moment I
> cannot think of a better solution :-(
Additionally see also:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337787#c3
Comment 3 Rüdiger Herrmann CLA 2011-06-01 11:40:51 EDT 
As it turned out, storing the ApplicationContext in the session is also necessary to have access to the ApplicationContext from background threads (with UICallback#runNonUIThreadWithFakeContext). This makes it impossible to give up buffering the ApplicationContext in the SessionStore