Portlets, HttpSession, and Thread Safety

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

The portlet specification (JSR-168) writes:

PLT.5.2.4.3 Multithreading problems in query processing

A portlet container handles simultaneous requests to a single portlet while executing request processing methods on different threads. Portlet developers need to design their portlets to handle concurrent execution from multiple threads from within processAction and render at any given time.

I wonder how should I achieve this? Of course, I can use synchronization to achieve mutual exclusion during processAction and render , but I don’t see how I can ensure atomic processing of requests in general. In particular, I am worried about the following scenario:

  • Thread 1 performs a processAction , loading data into the session for later rendering
  • Thread 2 performs processAction , dropping this data from the session
  • Thread 1 executes render , reading the data for rendering from the session and throws a NullPointerException because there are no more prepared data ...

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

+4
source share
1 answer

I would say that if there are two portlets running on the same data, especially one reading, and the other removes it, most likely a serious design flaw.

Then you may want to save the data in the portlet / stream, i.e. if portlet1 reads some data, you must write its lock until the reading is complete and put into the session using a unique key.

If it is legal to delete data that should be displayed, then you should consider this and check again during render .

+1
source

Source: https://habr.com/ru/post/1344924/


All Articles