[rhq-project/rhq] 344059: [1159003] Alert notification sending fails due to ...

[Jay Shaughnessy]

Branch: refs/heads/release/jon3.3.x
  Home:   https://github.com/rhq-project/rhq
  Commit: 344059de2d83d85fa46af8477eeb9419cb82c514
      https://github.com/rhq-project/rhq/commit/344059de2d83d85fa46af8477eeb9419cb...
  Author: Jay Shaughnessy 
  Date:   2015-01-08 (Thu, 08 Jan 2015)

Changed paths:
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertConditionLogManagerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertConditionManagerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertConditionManagerLocal.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertManagerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/AlertManagerLocal.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/CachedConditionManagerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/CachedConditionManagerLocal.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/alert/engine/jms/AlertConditionConsumerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/cloud/instance/CacheConsistencyManagerBean.java
    M modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/cloud/instance/CacheConsistencyManagerLocal.java

Log Message:
  -----------
  [1159003] Alert notification sending fails due to database deadlock error
Remove the umbrella Tx surrounding sending of alert notifications.  It used
to be that all notifications would be sent in one REQUIRES_NEW SLSB call. It
was necessary to do this because the notifications were themselves sent
within a larger, very heavy, umbrella Tx that involved the alert generation
itself (among other things). Prior work restructured that logic and
moved notification sending to a more logical place, executing after
alert generation, cache update and recovery logic handling.  But the prior
work left the notification sending under a single transaction.  This
isn't really necessary or desirable. Each notification should be processed
individually, not holding any resources past its execution, and
persisting each notification log in its own Tx.  Although not proven,
the deadlock situation was likely caused when an alert definition defined
multiple notifications, and one held resources required by another.

Also, rename some local SLSB methods with "Tx" suffixes to better reflect
their behavior.

(cherry picked from commit 9485d519fffbcaa55f100c691def6b6cae2564d9)
Signed-off-by: Libor Zoubek