Portlets, HttpSession and Thread-Safety

Question

Our portlets keep state in the HttpSession, which is shared by all request processing threads for the same session.

The portlet spec (JSR-168) writes:

PLT.5.2.4.3 Multithreading Issues During Request Handling

The portlet container handles concurrent requests to the same portlet by concurrent execution of the request handling methods on different threads. Portlet developers must design their portlets to handle concurrent execution from multiple threads from within the processAction and render methods at any particular time.

I wonder how I am supposed to achieve that? Sure, I can use synchronization to achieve mutual exclusion during both processAction and render, but I don't see how I can enforce atomicity of request processing as a whole. In particular, I worry about the following scenario:

• Thread 1 executes processAction, loading data into the session for later rendering
• Thread 2 executes processAction, discarding that data from the session
• Thread 1 executes render, reading the data to render from the session, and throws a NullPointerException because the prepared data is no longer there ...

How is that scenario usually prevented? In particular, when using the JBoss portlet bridge to adapt JSF to a Portlet environment?

Answer 1

I'd say that if there are two portlets operating on the same data, especially one reading it while the other deletes it, there's most likely a serious flaw in the design.

You might then want to store the data per portlet/thread, i.e. if portlet1 reads some data you should write lock it until reading is finished and put it into the session using a unique key.

If it is legal to delete data that should be rendered, then you should account for that and check again during render.