[
https://issues.apache.org/jira/browse/TRINIDAD-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399362#comment-13399362
]
Vijay Raghav commented on TRINIDAD-2278:
-----------------------------------------
We looked into the Trinidad code further and we could find two occurrence of
synchronized (session) in two different classes.
1.TokenCache.java
2.StateManagerImpl.java
In both the places the that the session object which is being synchronized can
be either HTTPSession or PortletSession
This is what the java docs say about ExternalContext.getSession()
public abstract java.lang.Object getSession(boolean create)
If the create parameter is true, create (if necessary) and return a session
instance associated with the current request. If the create parameter is false
return any existing session instance associated with the current request, or
return null if there is no such session.
Servlet: This must return the result of calling getSession(create) on the
underlying javax.servlet.http.HttpServletRequest instance.
Portlet: This must return the result of calling getPortletSession(create) on
the underlying javax.portlet.PortletRequest instance.
Parameters:
create - Flag indicating whether or not a new session should be created if
there is no session associated with the current request
Approaches tried :
===============
- We tried to synchronize session.getId().intern() which is a string value and
is unique for a session. However since the session object can be either
HTTPSession or PortletSession we could not use the same.
- Trinidad suggested to use a simple lock around the code. However we believe
that this will be of no use.
Conclusion :
==========
Finally we came to a conclusion that if we change the synchronized (session)
to anything different, then the code would not work the way it is designed to.
And synchronized (session) should not be changed.
Suggestions :
==========
Adding below piece of code just above the synchronized (session) will reduce
the probability of causing deadlocks to some extent.
TokenCache cache = (TokenCache) external.getSessionMap().get(cacheName);
if ((cache == null) && createIfNeed)
Updated method getTokenCacheFromSession() of TokenCache.java is as below.
static public TokenCache getTokenCacheFromSession(
FacesContext context,
String cacheName,
boolean createIfNeeded,
int defaultSize)
{
ExternalContext external = context.getExternalContext();
Object session = external.getSession(true);
assert(session != null);
TokenCache cache = (TokenCache) external.getSessionMap().get(cacheName);
if ((cache == null) && createIfNeed)
synchronized (session)
{
cache = (TokenCache) external.getSessionMap().get(cacheName);
if ((cache == null) && createIfNeeded)
{
// Seed the token cache with the session ID (if available)
int seed = 0;
if (_USE_SESSION_TO_SEED_ID)
{
if (session instanceof HttpSession)
{
String id = ((HttpSession) session).getId();
if (id != null)
seed = id.hashCode();
}
}
cache = new TokenCache(defaultSize, seed);
external.getSessionMap().put(cacheName, cache);
}
}
return cache;
}
Similar approach can be used for method getPerSessionApplicationViewCache() of
StateManagerImpl.java
Could you please look into the above analysis and suggestions. And it would be
great if you look into this issue and provide a suitable fix for this issue.
> HttpSession inside a synchronized block in the class TokenCache of
> trinidad-impl-1.0.10.jar could cause to deadlock while used with WAS 7
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-2278
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2278
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.10-core
> Reporter: Reshmi Choudhury
>
> Hi,
> We are using trinidad-impl-1.0.10.jar in our product. I see that HttpSession
> is used in a synchronized block in the class TokenCache of
> trinidad-impl-1.0.10.jar. Could you please clarify if this could cause to
> deadlock while used with WAS 7.
> Please find the below code snippet for your quick reference.
> static public TokenCache getTokenCacheFromSession( FacesContext context,
> String cacheName, boolean createIfNeeded, int defaultSize) {
> ExternalContext external = context.getExternalContext();
> Object session = external.getSession(true);
> assert(session != null);
> TokenCache cache;
> // Synchronize on the session object to ensure that
> // we don't ever create two different caches
> synchronized (session)
> {
> cache = (TokenCache) external.getSessionMap().get(cacheName);
> if ((cache == null) && createIfNeeded)
> {
> // Seed the token cache with the session ID (if available)
> int seed = 0;
> if (_USE_SESSION_TO_SEED_ID)
> {
> if (session instanceof HttpSession)
> {
> String id = ((HttpSession) session).getId();
> if (id != null)
> seed = id.hashCode();
> }
> }
> cache = new TokenCache(defaultSize, seed);
> external.getSessionMap().put(cacheName, cache);
> }
> }
> return cache;
> }
> This information is required as IBM informs the developer not to synchronize
> the session or it will cause deadlocks. WAS 7 implements the Servlets 2.5
> specification and manages the thread safety for any modification to the
> session map. Please refer to the URL
> http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/uprs_rsession_manager.html
> for more details. This URL contains this text:
> “Applications cannot synchronize session objects inside of their servlets or
> Java Server Pages because a deadlock with the session manager may occur. The
> deadlock occurs because the session manager does not expect the use of more
> than one locking mechanism”
> Here is an excellent article on this topic, which explains when explicit
> synchronization is needed in the application code and when the servlet
> container's locking mechanism is sufficient:
> http://www.ibm.com/developerworks/library/j-jtp09238/index.html
>
> It would be really helpful if we receive the information at the earliest as
> this is priority at our end.
> Thanks in advance.
> Regards,
> Reshmi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
