myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan (JIRA)" <>
Subject [jira] [Commented] (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
Date Fri, 22 Jun 2012 15:38:42 GMT


Scott O'Bryan commented on TRINIDAD-2278:

1) why would a lock not work?  The lock ensures caching of critical sections is release before
the lock is complete, and the thread-safe nature of HttpSession will ensure order.  I'm not
sure how using a Lock wouldn't work?  In either case, using a temporary object and doing a
syncronize on that should work fine also (Just be a bit slower)..

private static final Object _LOCK_OBJECT = new Object();

syncronized (_LOCK_OBJECT)

2) Trinidad versions later then 2.0 use ExternalContextUtils for this type of information
and it's coded to work with the portlet.  You can do something similar here.  OR, since 1.0
is no longer maintained and the patch will be unofficial anyway, you can probably just worry
about the servlet case and let any portal people worry about portal usecases.  Trinidad 1.0
predated any known bridge and the initial releases of the bridge built into MyFaces 1.0 and
1.1 would not run it anyway.  It wasn't until the JSR-301 bridge that portal was expressly
supported and that started with Trinidad 1.2.

Just my .02..
> 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:
>             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
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:
> 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:!default.jspa
For more information on JIRA, see:


View raw message