[jira] [Comment Edited] (TRINIDAD-2278) 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

["Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397968#comment-13397968 ] 

Scott O'Bryan edited comment on TRINIDAD-2278 at 6/20/12 10:51 PM:
-------------------------------------------------------------------

I think you're right on here Reshmi.  However the syncronization is needed for other reasons.  Although the HttpSession itself will not run into threading issues, that is not to say that the code which uses it won't.

Truth be told, aside from the deadlock issue, this isn't even guaranteed to work because there is no guarentee the session instance is the same between threads.

In later Trinidad releases, I would say this should be replaced with a lock.  Since session is thread safe, we do not have to worry about any caching issues from the object, so a simple lock around the code would suffice.  For this branch of Trinidad, I suppose you could syncronize on the tokenCache itself or create another lock object to syncronize on.

Do keep in mind that 1.0 is no longer maintained, but I do invite you to provide a patch here that other people can apply to the latest trunk manually.  Thanks for your interest.
                
      was (Author: darkarena):
    I think you're right on here Reshmi.  However the syncronization is needed for other reasons.  Although the HttpSession itself will not run into threading issues, that is not to say that the code which uses it won't.

Truth be told, aside from the deadlock issue, this isn't even guaranteed to work because there is no guarentee the session instance is the same for two sessions.

In later Trinidad releases, I would say this should be replaced with a lock.  Since session is thread safe, we do not have to worry about any caching issues from the object, so a simple lock around the code would suffice.  For this branch of Trinidad, I suppose you could syncronize on the tokenCache itself or create another lock object to syncronize on.

Do keep in mind that 1.0 is no longer maintained, but I do invite you to provide a patch here that other people can apply to the latest trunk manually.  Thanks for your interest.
                  
> 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