Investigate the benefits of using internal locks rather than synchronizing (locking) on the current instance (this) or the class

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: None
• Fix Version/s: None
• Component/s: JSF Showcase, Liferay Faces Alloy / Showcase / Tests, Liferay Faces Bridge API, Liferay Faces Bridge Ext, Liferay Faces Bridge Impl / Demos / Tests, Liferay Faces Portal / Demos / Tests, Liferay Faces Util
• Labels: None

This task involves investigating the benefits (and drawbacks) of using internal instance or static members for synchronization. Java: Concurrency In Practice (p. 61) states:

There are advantages to using a private lock object instead of an object's intrinsic lock [ for example synchronized (this) ] (or any other publicly accessible lock). Making the lock object private encapsulates the lock so that client code cannot acquire it, whereas a publicly accessible lock allows client code to participate in its synchronization policy---correctly or incorrectly. Clients that improperly acquire another object's lock could cause liveness problems, and verifying that a publicly accessible lock is properly used requires examining the entire program rather than a single class.

As part of this task, a consistent policy towards intrinsic locks (locking on this ) and locking on .class es should be determined, and the code should be made to consistently utilize either intrinsic/public locks or private locks.