[
https://issues.apache.org/jira/browse/TRINIDAD-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401744#comment-13401744
]
Blake Sullivan commented on TRINIDAD-2278:
------------------------------------------
As you guys figured out, this code is working as intended--the requirements are
to:
1) Guarantee that only a single instance of the token cache is created per
session
2) Only lock the current session
We should not change this without more information regarding in what use case
IBM believes that this usage
It is funny that the IBM documentation refers to Java Concurrency in Practice
as the book explicitly talks about how the Servlet Specification is lame
because:
a) It doesn't expose any ConcurrentMaps
b) It doesn't give access to any internal lock object
c) It doesn't document whether external locking is allowed
The upshot is the applications are really left with only one option--sse
external locking and hope for the best (what TokenCache is doing).
There are two other options that might seem appealing, but they have their own
issues:
1) Create a finer-grained Serializable object, store that in the Session and
make sure that all ConcurrentMap-style operations on an attribute lock on that
lock object
This unfortunately has all of the same--How do I avoid creating this lock
object twice problem that we are trying to solve
2) Lock on the SessionMap
Unfortunately, the SessionMap instances may have a many-to-one relationship
with the actual Session object, so this doesn't work
> 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
