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

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: None
• Fix Version/s: alloy-1.0.2, alloy-2.0.2, portal-1.0.2, portal-2.0.2, util-1.1.1, util-2.1.1, bridge-impl-2.1.1, bridge-ext-1.0.2, bridge-ext-2.0.2, bridge-ext-3.0.2, bridge-ext-4.0.2, bridge-api-2.1.1, bridge-api-3.1.1, bridge-impl-3.1.1, bridge-impl-4.1.1, util-3.1.1, bridge-impl-6.0.0, portal-3.0.2, bridge-ext-5.0.2, alloy-3.0.2, bridge-api-4.1.1
• 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.