JBPM execution issue on Linux and Mysql

Recently I got to work with JBPM, one of the popular BPM suites in use. Additionally open source. The API was exhaustive and the whole concept was awesome to lean and use. The distribution comes bundled with JBoss and instructions for deploying on any other application server.

I tried deploying the same on my favorite Pramati Server (Version 6.0). It was straight enough to be called smooth deployment. Throughout my learning process I did not face any issues with JBPM and I was more than happy to have been introduced to JBPM, untill it was deployment time.

We had an application developed with JBPM as the backbone for ProcessFlow management. My development Environment was Windows.

MySql database on windows Xp (mysql Ver 14.12 Distrib 5.0.27, for Win32 (ia32))
Mysql Connector JDBC Driver (mysql-connector-java-5.0.6-bin.jar)
Pramati Server 6.0 SP1 on Windows Xp
JDK 1.5.0_11 on windows

Where as the deployment Environment was Linux

MySql database on linux 2.6.18-8.el5 on i386/i686 (mysql Ver 14.12 Distrib 5.0.22, for redhat-linux-gnu (i686))
Mysql Connector JDBC Driver (mysql-connector-java-3.1.11-bin.jar)
Pramati Server 6.0 SP1 on on linux 2.6.18-8.el5 on i386/i686

In the deployment environment, to my surprise the process flow execution did not proceed as expected.

Manifestation of the issue on the Deployment (Linux) setup:
1. When start task execution was called for, it executed asynchronously, even if there was no asynchronous flag set in the process definition.
2. Completion of a start task should always lead to a signal which did not happen.
3. When the signal was forced manually, the root token of execution entered the next node. however the tasks that are to be instantiated were not instantiated.
4. Further node movements of the token were signaled automatically and the process instance ended without instantiating any of the desired tasks.

After a lot of debugging, I could arrive at the source of the issue:

Source of the issue:
1. The asynchronous execution of the start task was because the task instance was marked as Asynchronous when hibernate retrieved the the task definition from the underlying DB.
2. Signaling issues were because of similar erroneous flags in the Hibernate retrieved entities
3. Task creation failure too was because of a flag which controlled creation of task for specific nodes and was being set as false on the entities retrieved by hibernate.

All this pointed out that the definition of the claim process is somehow incorrect as it is in the database. When I tried with detailed debugs both on hibernate and JBPM, it was clear that the definition was getting converted correctly in to entities ans persisted correctly too. Then the next suspect was retrieval. This is where the crux of the issue was.

Cause of the issue:
Bit data type has certain issues in Mysql. Somehow the way it should be dealt with, by several ORM solutions, is not error free. More on this at the following links:

http://opensource.atlassian.com/projects/hibernate/browse/HBX-729
http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/
http://blog.cherouvim.com/overcoming-the-mysql-bit-datatype-problems-with-hibernate/

Hibernate was saving the flags which are of bit data type as per the distibution in JBPM. While retrieving is was meshing up with the values and we saw all kinds of troubles during the execution. Bit data type was supposed to behaving similar to tinyint which has been there on mysql for long. Apparently it is not.

Solution:
There were two ways to handle the issue.
1. Moving to a newer version of JDBC jar(Some suggested )
2. Changing the DB definition to tinyint
3. Telling hibernate to treat those columns as tinyint through the hbm xml files

Well Changing the JDBC jar did not help. (I had enough expectations though. A similar setup with the mysql-connector-java-5.0.6-bin.jar worked smoothly on Fedora Core 7 linux)

The second option worked for me. When I replaced all the column definitions to tinyint in place of bit for the JBPM DB. And things started working like charm in the deployment environment. I tested the application for the whole work flow cycle without any trouble.

TINYINT did the magic for me. You can give the third option a try though and see if it does the magic too.

Cheers