Context
======
When a deployment with duplicate filtering is performed, the following transaction is run:

Given: deployment with name=foo, resources=[process1.bpmn]

1. check database for the last deployment with name "foo" (sort by Timestamp)

2. if found,
diff resources
if resources not changed resume existing deployment
else create new deployment
else create new deployment

3. for each process definition in the deployment (new or existing)

• if version > 1 resume all previous versions of process definition

Problem Description
================
Given: Cluster with two nodes A and B such that clock(B) = clock(A) - 10s
(ie. the clock on node B is 10 seconds behind node A.)

If the deployment is performed on both nodes simultaneously, the following can happen:

• Both transactions check the database for an existing deployment: assuming that none of the transactions has committed yet, both create a new deployment.
• The Process Definition is parsed and when done, the version is checked.
• But before the version check is performed on node B, node A commits.
• As a result, Node B will deploy version 2 of the process

Now the process applications are redeployed:

• in Step 1 of the deployment transaction, the latest version of the deployment is fetched. Since the clock on Node B is behind Node A, Version 1 of the Deployment is returned and the process application creates a registration for this version.
• But, runtimeService.startProcessInstnaceByKey() will start Version 2

=> since no registration exists for Version 2, a class not found exception is thrown when a service task is executed.

Proposed Fixes
============

• Deployment Transaction requests a pessimistic LOCK on the ACT_RE_DEPLOYMENT_ table