Before I answer this question, consider:

What are you actually trying to accomplish? Are you sure that you need share session data to fulfill your goal? Can you use another (better) method to share data between several portlets across several requests?

David Nebinger, Liferay expert and prolific community member, has said that "Session Storage is Evil." Perhaps you could dismiss his statement as hyperbole, but considering all his supporting evidence (and other experts who have echoed his concerns), 1 I think that would be a mistake. Storing (and sharing) data in the session has many drawbacks. For example, sessions must be replicated in a cluster or risk data loss and a disruptive user experience, data in the session must be accessed/modified in a thread-safe way, and any session data increases your application’s memory footprint and reduces scalability. More importantly, the HttpSession (which the PortletSession is based on) is not designed for sharing data between applications (see Servlet Spec 3.1 Section 7.3: Session Scope). Finally, sharing data via the session creates tight, opaque coupling between applications. So before you store and share any data via the PortletSession, consider the following alternatives:

Ultimately, Public Render Parameters (PRPs) are stored in the session (in Liferay’s implementation at least), so they still have some similar drawbacks to session storage. However, PRPs are limited to strings, so their impact on memory is less extreme than other objects that might be stored in the session. Also PRPs are more clearly defined and allow more loose coupling between portlets than shared session data. They also provide bookmarkability with idempotent URLs. Use PRPs to share data such as database keys and similar strings that allow other portlets to determine what or how certain data should be displayed. PRPs should not be used to mutate model data in other portlets, unlike Portlet Events.

Events don’t use session storage, so they will usually have less of an effect on your application’s memory footprint than session data. Although events might require more complex code than PortletSession.get/setAttribute(), events (like PRPs) enable clearly-defined, loose coupling between portlets via the publish/subscribe design pattern. Use Portlet Events when an action in one portlet may be interesting and even provoke changes in data in another portlet.

Persisting data to the database with Service Builder is an extreme option with potential drawbacks for scalability and increased complexity. Creating a new Service with Service Builder, potentially adds two new JARs to your project. However, it will ensure that the data is available to all portlets via the service APIs. You can also enable caches to improve scalability. Perhaps the data you are sharing in session storage is not really temporary or it should be preserved even if a server goes down. In that case, you should use Service Builder.

Hopefully 99.9% of people have decided to use PRPs, Events, or Service Builder to share data between portlets and have stopped reading at this point. But for the sake of the 0.1% who legitimately need to use session sharing, I’ve provided a list of ways that you can do that. However, I must again urge caution when relying session sharing and using session storage in general. Please make sure that you are following best practices so that the “easy-to-use” session doesn’t become a source of impossible-to-debug problems. To that end, I encourage you to use the earlier entries in this list and limit the state that is shared between the portlets as much as possible.2

Use PortletSession.APPLICATION_SCOPE to share one or more session attributes between portlets in the same application/WAR.

For example:

Use Liferay session.shared.attributes prefixes (such as LIFERAY_SHARED_) to share one or more session attributes between portlets in different applications/WARs.

Liferay exposes certain session attributes to all portlets based on certain prefix values. Although these prefixes are configurable via portal-ext.properties, I recommend using one of the default prefixes: LIFERAY_SHARED_.

For example:

Use false (in your liferay-portlet.xml ) to share all session data between portlets in different applications/WARs.

For example:

Portlet A:

liferay-portlet.xml:

Portlet B:

liferay-portlet.xml:

Access the HttpSession by unwrapping the HttpServletRequest from the PortletRequest.

Don’t do this. It’s not guaranteed to work in Liferay 7.0+ since you may not be able to access the app server’s HttpServletRequest and you can accomplish essentially the same goal with #3.