to quartz or not to quartz
i was really convinced of proving that i don't suffer the not invented here (NIH) syndrome. so i was going to use quartz to fix the asynchronous command and scheduler problems.
In summary: the quite heavy integration layer that is necessary between quartz and jbpm (mainly jdbc connection and transaction integration) makes is more difficult to create a supportable jbpm. On the other hand, looking at quartz made me realize how we can easily upgrade our current timer/messaging mechanism to make it as robust as quartz.
currently this is where i stand: i have completed the quartz customization classes to get the jdbc connection and transaction behaviour that i want:
all of what follows is only intended to run on a standard java environment. for enterprise environment, we're going to build an ejb-timer-service based implementation.
jBPM's timer requirements are quite basic. jBPM managed the code to be executed. The thing i need is a few basic operations to insert and cancel timers. On the other hand, i need a Job execution algorithm.
* for managing jobs and triggers (user operations coming from the process definitions), the same jdbc connection should be used as for the jbpm process updates.
* for quartz internal transactions, quartz should obtain its own JDBC connections and manage the transactions on those connections.
There is only one job store that makes the separation between these two types of quartz transactions: JobStoreCMT. In fact, by reading that job store and related docs, i discovered that quartz needs two types of transactions, one type of transactions is for user operations and one type of transactions is for quartz internal stuff.
Next i would have to write a Job that contains a reference to a jbpm action.
It seems to me that i have gone through quite a bit of trouble to remove and work around the quartz behaviour that i don't need in jBPM. Most of the existing quartz knowledge cannot be used since we have to go through quite a few hoops to get it working. That integration will be quite tricky to explain to our users and to support our customers.
Another downside that i see is that quartz uses it's own object to JDBC mapping. They support quite a few databases, but it reduces the chance of things running smooth out of the box. Also configuration management becomes a lot more difficult if you have to maintain the jbpm-hibernate configurations separate from the quartz configurations. Also the schema is a bit big for what we need.
The question is mainly: is the part of quartz that we use worth while all this trouble. I have definitely seen a simple solution for the current problems that we currently have with our initial timer and messaging services. The trick that quartz uses is having out-of-bound transactions and/or database pessimistic locking.
I have gone as far as that i can see how we can get it to work. This resulted in a lot of configurations and assumptions on how quartz is used in jBPM. So the bigest resistence i have to go for quartz is support. If we use quartz, chances are that our users will use quartz in ways that conflict with the assumptions that we have made now: responding to those inquiries and bug reports is going to take a lot of time because the debugging will be mostly in the highly customized jbpm-quartz integration. That is a level of abstraction extra versus the do-it-yourself-invented-here approach.
