Posted by: kukeltje | 17 December, 2008

jBPM “supported” target databases… H2 anyone?

It’s not a well kept secret that jBPM runs on many databases (it uses hibernate), although one ‘competitor’ still states on its website that it only supports one… duh. Since a few months this is being ‘professionalized’ further by making sure a full QA environment is being setup to actually test as many databases as possible. This of course takes time, but with the help of two new additions to the team, things are coming along nicely. The officially supported databases can be found at the ‘jBPM Supported Target Databases’ page in the wiki. Some might be surprised that Oracle is not in there yet, as was a poster with some fork-join problems with Oracle In one of his posts he states:

It struck me that jBPM is not tested properly with one of the most widely used databases in the world.
We also ran into some other problems with the jBPM console and hot process deployment from eclipse when running on a oracle database.
We can’t start process instances from the console and hot deployment is not possible when using oracle.

I would think that the oracle and mssql database should be the top priority databases to test against!.

Fair? hmmm… yes and no. That is why I put “supported” in quotes.  According to the wiki pages it is not officially supported. The meaning of this table is that jBPM has run a required set of tests against that database. Some tests might be excluded (see the wiki or the pom files in the project).  It does not mean there is no knowledge about these databases within the jBPM team. JBoss employees (I have to mention Martin Putz here whom I never met yet) or the community. Within 3 hours, the free support on Oracle via the community made clear that the ‘other problems’  were caused by a human error. The Oracle sequences were not in the jBPM database because two applications had different hibernate configs but pointed to the same database. One with create-drop (a seam (-gen test?) app) and one with none (jBPM).

It turned out his problem with the fork-join could be caused by a regression that might have been caught if the QA environment had Oracle in it. Or does it… The usecase he has is maybe not that common. Some of the legs of a fork go to a decisionnode which has one of it’s outcomes go directly to the join, so no persistent state in between. There is no testcase for this in the testsuite so it would not have been caught directly, but it might have showed up in a different test.  As you can see in his initial post, all effort is being made to tackle this problem. Tesiting with different versions of jBPM against different databases by more than one person and the original poster helping out, not sitting back. Tell me, did anyone ever did get this type of support from other ‘vendors’?

This brings me to one of the other statements made by the poster

When running hsqldb these things work ok.

Lately the jBPM team more and more runs into limitations of HSQLDB. For me, I’d not try to find causes for errors on this database since it is clearly not ‘enterprisy’. For a long time, originally intiated by a post in the ESB forum I’ve had the itch to ditch HSQLDB. This never lead to anything, but for me this was the moment to do it…. And sometimes you are lucky, wish you had done it earlier: It took me only two hours to make H2, the best alternative to me, part of my jBPM project. Well, not completely, the enterprise part was not tested yet, but that is just a matter of some more time.

Now I could run the unit test that I made for the problem above run against 3 databases locally. HSQLDB, H2 and MySQL. All tests (except the excluded ones for HSQLDB) run fine… even against H2… isn’t that great…One small thing I had to do is adapt the connect string a little to

jdbc:h2:~/jbpm;MVCC=TRUE;

Otherwise one multithreaded jobexecutor test would create deadlocks. I recognized the param from an ESB config I came across while searching the web. If it is good for them, it is good for us to.

But… and now comes the big surprise. H2 can run in a compatibility mode. Not SQL-92, SQL-99, SQL-2003 stuff, no Oracle, PostgreSQL, MySQL, MSSQL, Derby, HSQLDB. Yeah right… Well, I gave it a try… changed the dialect to Oracle and added the right mode in the connect string and ran the test. To my big surprise I was able to duplicate the results Martin had on Oracle and PostgreSQL,  wow… The results on MySQL were a little different, but it might be that I should use a different dialect then the InnoDB one… well… since I have a real MySQL, that is of less interest to me.

So for me, the fact that H2 also can be embedded even in-memory, has a much nicer web ui than HSQLDB and just feels better, would be a reason to add it to jBPM and even to the supported target databases (it’s not even on the list, but it is a wiki page so I can at least add it without the ‘check marks’ )

That leaves me with just one statement from the original poster

Is raises the question whether jBPM is the right choice for enterprise software??

Ok, I’m biased, have some inside information to where jBPM all runs, but do not get paid by jBPM to state this: The answer is definately yes and even more so if you look at support as more than a checkmark in a table (and don’t make any more stupid mistakes Jan or rush to conclusions ;-))

About these ads

Responses

  1. Thanks for the interesting overview on your database support.

    Most interesting I find are your findings on the in-memory choices. All developers should take note and be interested in working with such databases, be that you can facilitate your (unit) testing nicely with these. Something I wish I encountered more in practice than I do…

  2. We have been using H2 for unit testing for some time now, replacing HSQLDB because we need JTA XA support (and HSQLDB does not offer it, while H2 does). Never had a single problem. H2 works greatly!

  3. I’m curious why you don’t just set up an Oracle XE instance and add it to the test suite of databases? Oracle XE is free to install (I’d be surprised if your test suites would run into the 2GB limitation). As the poster pointed out it’s very widely used…

    • Uhhhmmm… I think you missed the point of my post. I did not try to setup H2 to emulate Oracle, I tried it so it could be a replacement of HSQL. The fact that Oracle is not (yet) in the supproted target databases is beyond my influence since I do not work for JBoss. While setting up H2 I saw the emulation mode and it surprised me that running it in emulation mode I got the same error as on a real Oracle… good emulation that is.

      Sybase is in the QAS matrix because a customer who bought support had some issues with jBPM on Sybase. Sure, Oracle XE is free, but someone has to take the time to install it, maintain it etc. In addition to this you could also state that since there are so limited issues on Oracle the need is less and once there is an issue, support is provided. Everything in due time… (e.g. the now maturing jBPM QA becoming part of the larger JBoss QA)

  4. It took me only two hours to make H2, the best alternative to me, part of my jBPM project.

    I’m running into hibernate/sql errors when trying to configure H2 for jBPM 3.x. Can you post snippet of changes you have done to make it work?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: