jBPM “supported” target databases… H2 anyone?
Blog: PlanetjBPM's Weblog
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 ;-))
Leave a Comment
You must be logged in to post a comment.
