Database upgrades from jBPM 5.4 to jBPM 6

Posted on April 25, 2014 by Evan Knowles — 3 Comments ↓

Contents

1 Introduction
2 Fixing the Sequences
- 2.1 New Sequences
- 2.2 Correcting Increment By
3 Fixing Runtime Deployment Id
4 Complete Oracle Code
5 Conclusion

Introduction

I’ve recently had to convert a currently in-use production system running in jBPM 5.4 to jBPM 6.

The jBPM 6 team did make an attempt to make the upgrade process fairly easy by ensuring that they only added columns and objects. Theoretically this would mean that Hibernate’s included update process would be able to migrate the database automatically.

This almost works, but not completely. The issues are mostly in the included new drools packages involving sequencing, as well as the addition of the runtime deployment ID in the drools code where we need to manually correct the database.

You’ll need to run these fixes after the launch of the app server if you plan to use these fixes in conjunction with Hibernate’s update, so you may want to instead build up a script of the upgrade changes and avoid using Hibernate’s update altogether.

Fixing the Sequences

New Sequences

As part of jBPM 6, it seems that several entities that were previously using the default HIBERNATE_SEQUENCE are now using their own sequences. Specifically, I found process_instance_info_id_seq and task_id_seq sequences are new.

The process_instance_info_id_seq should be set to the value of HIBERNATE_SEQUENCE + 51 , for safety. This is because that sequence’s Increment By value is using the default of 50.

The task_id_seq sequence should be set to the HIBERNATE_SEQUENCE sequence’s value.

Correcting Increment By

Other sequences were previously using different default values of ‘Increment by’. It seems logical that this must be due to a newer version of Hibernate being used – previously a value of 1 was being used, whereas the default is now 50. As the sequence already exists, Hibernate does not update it.

This can cause some weird issues where, due to the HiLo sequence generator being used, identity values which are already used are generated. This then causes unique constraint violation exceptions to be thrown, specifically in sessioninfo_id_seq and workiteminfo_id_seq , both of which should be changed to increment by 50 instead of the previous 1.

Fixing Runtime Deployment Id

A runtime deployment ID is now associated with the tasks. As it is a new column, it is null for any existing tasks. This causes an issue when jBPM attempts to look up the runtime to work with the task.

You can simply set the deploymentid to an appropriate default value for your system. For example, if you’re using the singleton runtime manager, you could do:

  update task
     set deploymentid = 'default-singleton'
   where deploymentid is null;

update task

set deploymentid = 'default-singleton'

where deploymentid is null;

Complete Oracle Code

Here’s my complete update script for Oracle:

declare

  hibernate_val    NUMBER;
  task_id          NUMBER;
  process_instance number;

BEGIN
  --SELECT HIBERNATE_SEQUENCE.nextval into hibernate_val from dual;
  hibernate_val := HIBERNATE_SEQUENCE.nextval;
  DBMS_OUTPUT.PUT_LINE('sequence: ' || hibernate_val);

  -- task_id_seq update to the next hibernate value
  EXECUTE IMMEDIATE 'ALTER SEQUENCE TASK_ID_SEQ increment by ' ||
                    hibernate_val;
  SELECT TASK_ID_SEQ.nextval into task_id from dual;
  DBMS_OUTPUT.PUT_LINE('task id: ' || task_id);
  EXECUTE IMMEDIATE 'ALTER SEQUENCE TASK_ID_SEQ increment by 1';

  -- process_instance_info_id_seq update to the next hibernate value + 50 
  EXECUTE IMMEDIATE 'ALTER SEQUENCE process_instance_info_id_seq increment by ' ||
                    (hibernate_val + 50);
  SELECT process_instance_info_id_seq.nextval
    into process_instance
    from dual;
  DBMS_OUTPUT.PUT_LINE('process instance id: ' || process_instance);
  EXECUTE IMMEDIATE 'ALTER SEQUENCE process_instance_info_id_seq increment by 50';

  EXECUTE IMMEDIATE 'ALTER SEQUENCE sessioninfo_id_seq increment by 50';
  EXECUTE IMMEDIATE 'ALTER SEQUENCE workiteminfo_id_seq increment by 50';

  update task
     set deploymentid = 'default-singleton'
   where deploymentid is null;
END;

declare

hibernate_val NUMBER;

task_id NUMBER;

process_instance number;

BEGIN

--SELECT HIBERNATE_SEQUENCE.nextval into hibernate_val from dual;

hibernate_val := HIBERNATE_SEQUENCE.nextval;

DBMS_OUTPUT.PUT_LINE('sequence: ' || hibernate_val);

-- task_id_seq update to the next hibernate value

EXECUTE IMMEDIATE 'ALTER SEQUENCE TASK_ID_SEQ increment by ' ||

hibernate_val;

SELECT TASK_ID_SEQ.nextval into task_id from dual;

DBMS_OUTPUT.PUT_LINE('task id: ' || task_id);

EXECUTE IMMEDIATE 'ALTER SEQUENCE TASK_ID_SEQ increment by 1';

-- process_instance_info_id_seq update to the next hibernate value + 50

EXECUTE IMMEDIATE 'ALTER SEQUENCE process_instance_info_id_seq increment by ' ||

(hibernate_val + 50);

SELECT process_instance_info_id_seq.nextval

into process_instance

from dual;

DBMS_OUTPUT.PUT_LINE('process instance id: ' || process_instance);

EXECUTE IMMEDIATE 'ALTER SEQUENCE process_instance_info_id_seq increment by 50';

EXECUTE IMMEDIATE 'ALTER SEQUENCE sessioninfo_id_seq increment by 50';

EXECUTE IMMEDIATE 'ALTER SEQUENCE workiteminfo_id_seq increment by 50';

update task

set deploymentid = 'default-singleton'

where deploymentid is null;

END;

Conclusion

These corrected all of the database migration related issues I was experiencing. Leave a comment if you found any others and I’ll update the page.

Tagged with: database, java, jbpm
Posted in Java

3 comments on “Database upgrades from jBPM 5.4 to jBPM 6”

Arif Mohammed says:

April 25, 2014 at 11:39 pm

It is a good start 🙂 Thank you.

Reply
Lawrence Lai says:

September 23, 2014 at 3:35 am

Great post! Thanks for your sharing.

Reply
TiOluwa Olarewaju says:

August 24, 2017 at 9:21 pm

Thank YOU!

Reply