Community
Participate
Working Groups
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?
(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 :-(
(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
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
