GET HTTP Session from serve resource

ibrahim magdy, modified 8 Years ago. New Member Posts: 20 Join Date: 7/14/10 Recent Posts
Hi every one,
i am trying to get Http session from serve resource method i use the following lines
"HttpServletRequest org = PortalUtil.getOriginalServletRequest(PortalUtil.getHttpServletRequest(request));
log.info(" session id ="+org.getSession().getId());"

but the session id printed is totaly different than the real http session id

note : when i use the same lines of code on render method not serve resource methods it works fine and return the same id
thumbnail
David H Nebinger, modified 8 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
They are not guaranteed to be the same session.

A render request is basically issued by the portal when it's main servlet is collecting content to aggregate a page. Therefore the request that you get in your portlet originates from the ROOT web application.

Serve resource requests, though, well they can go directly through your own portlet war, so it's through your own web app and therefore has your own session, not the portal session.

This is another reason to avoid session storage, as I've said before it is a miserable hack to begin with and it doesn't play well in a cluster. Whatever you're trying to store in the session should be persisted in a classic sense, not the hack of the session store.





Come meet me at the 2017 LSNA!
ibrahim magdy, modified 8 Years ago. New Member Posts: 20 Join Date: 7/14/10 Recent Posts
thanks for your reply

in my case i need to store a value that comes from external service which will be the same across the session and i want to access it while i make ajax calls so how can i achieve that when i have new session with every ajax call is there any alternative rather than keep it in the session
thumbnail
David H Nebinger, modified 8 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Yes there is a solution - avoid the session altogether.

Now that doesn't mean it has to be retrieved each time. You can, for example, leverage a SingleVMPool or MultiVMPool (for a cluster) which pushes retrieved values into a cache that is backed by ehcache and so it will expire and discard values. So basically you check the cache and, if it doesn't have the value, retrieve from remote service and store back in the cache.

But session storage is always, always a bad idea and a terrible hack.





Come meet me at the 2017 LSNA!