[
https://issues.apache.org/jira/browse/TRINIDAD-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott O'Bryan resolved TRINIDAD-2278.
-------------------------------------
Resolution: Won't Fix
> 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
