Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Date: Fri, 22 Jun 2012 15:38:42 +0000 (UTC)
From: "Scott O'Bryan (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Message-ID: <376584225.44274.1340379522750.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1317241720.33675.1340195262911.JavaMail.jiratomcat@issues-vm>
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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/TRINIDAD-2278?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
3399384#comment-13399384 ]=20

Scott O'Bryan commented on TRINIDAD-2278:
-----------------------------------------

1) why would a lock not work?  The lock ensures caching of critical section=
s is release before the lock is complete, and the thread-safe nature of Htt=
pSession 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 sho=
uld work fine also (Just be a bit slower)..


private static final Object _LOCK_OBJECT =3D 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 somethi=
ng 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 an=
d 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 t=
hat portal was expressly supported and that started with Trinidad 1.2.

Just my .02..
               =20
> HttpSession inside a synchronized block in the class TokenCache of trinid=
ad-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 HttpSess=
ion is used in a synchronized block in the class TokenCache of trinidad-imp=
l-1.0.10.jar. Could you please clarify if this could cause to deadlock whil=
e 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 =3D context.getExternalContext();
>     Object session =3D external.getSession(true);
>     assert(session !=3D null);
>     TokenCache cache;
>     // Synchronize on the session object to ensure that
>     // we don't ever create two different caches
>     synchronized (session)
>     {
>       cache =3D (TokenCache) external.getSessionMap().get(cacheName);
>       if ((cache =3D=3D null) && createIfNeeded)
>       {
>         // Seed the token cache with the session ID (if available)
>         int seed =3D 0;
>         if (_USE_SESSION_TO_SEED_ID)
>         {
>           if (session instanceof HttpSession)
>           {
>             String id =3D ((HttpSession) session).getId();
>             if (id !=3D null)
>               seed =3D id.hashCode();
>           }
>         }
>         cache =3D new TokenCache(defaultSize, seed);
>         external.getSessionMap().put(cacheName, cache);
>       }
>     }
>     return cache;
>   }
> This information is required as IBM informs the developer not to synchron=
ize 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/wasi=
nfo/v7r0/index.jsp?topic=3D/com.ibm.websphere.nd.multiplatform.doc/info/ae/=
ae/uprs_rsession_manager.html for more details. This URL contains this text=
:
> =E2=80=9CApplications cannot synchronize session objects inside of their =
servlets or Java Server Pages because a deadlock with the session manager m=
ay occur. The deadlock occurs because the session manager does not expect t=
he use of more than one locking mechanism=E2=80=9D
> Here is an excellent article on this topic, which explains when explicit =
synchronization is needed in the application code and when the servlet cont=
ainer's locking mechanism is sufficient:
> http://www.ibm.com/developerworks/library/j-jtp09238/index.html
> =20
> 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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira