Description:
Description:
===========
A node crash can cause in-doubt pending database transactions. This affects both processes that have already started, and those that are in the process of being started. A node restart resolves the in-doubt pending transactions for processes that have already been started.

For processes that are being started, the in-doubt pending database transactions are not recovered. This problem is indicated by processes that are stuck in the "Starting" state. To recover these transactions, use the workaround below.

Environment:
===========
   o TIBCO ActiveMatrix BPM 1.3.x (+ Hotfixes) or 2.0.x (+ Hotfixes).

Workaround:
==========
The exact workaround used depends on whether the client application has received correlation data:

* If the process is being started using Process As A Service (PAAS) with the Reply Immediately With Process Id option on the Start event, the client application will have the Process ID as correlation data. In this case, the stuck process should be recovered using the steps below in order to retain the same process ID that the client holds as correlation data.

* If the process is being started using PAAS with the reply (including correlation data) modeled within the process, the client application will not have received correlation data, and the process may be in an error state. In this case, it may be preferrable to cancel the process instance using the cancelProcessInstance API rather than recovering it. Doing this means the process instance is purged from the database and you must resend the transaction from the client.

To recover and reschedule stuck processes:

1. Resolve the pending transactions either in the Oracle database or by restarting the BPM Node that was shut down.

2. Query the database to find process instances that are in a starting state and are being processed:

   select pi.id,pi.owner_id,pi.group_id from pvm_inst_process pi
   where pi.status=50 and pi.id not in (select rq.datum from pvm_request_queue
   rq where pi.id = rq.datum)
   and pi.id not in (select pt.process_id from pvm_process_tracker pt where pi.id
   = pt.process_id and pt.engine_id != -1);

Where:

   pi.owner_id = module_id
   pi.id = process_id
   pi.group_id = group_id

3. Run the following SQL insert statement to reschedule the process instances:

   insert into pvm_request_queue
   (id,status,group_id,priority,request_type,datum,datum2,owner) values
   (&ltid>,0,&ltgroup_id>,200,101,&ltprocess_id>,&ltmodule_id>,-1);

   NOTE: Because the &ltid> parameter must be set so as to not conflict with
   other items in the request queue, the range should be 1..n depending on how
   many process instances are being rescheduled. Starting at "1" ensures that
   this id is unique.
Symptoms:

Cause: