I’m playing around with Quartz.net and adding support for a persistent job store via the ADO.NET Job Store. As per the recommendation, I’m instructing the job store to persist job parameters in plain text rather than BLOBs, using the configuration:
<add key="quartz.jobStore.useProperties" value="true"/>
Unfortunately in triggering a simple job, which has no explicit job data map, I receive this error:
JobDataMap values must be Strings when the 'useProperties' property is set. Key of offending value: LAST_MODIFIED_TIME
When looking in the debugger at the
JobDataMap object provided to the job I scheduled, there is no
LAST_MODIFIED_TIME present. Digging a bit deeper, it seems that there is another job running called
FileScanJob, scheduled by the
XMLSchedulingDataProcessorPlugin (used to read the job and trigger configuration from an XML file). This job adds the
LAST_MODIFIED_TIME entry to its
JobDataMap during job execution, which is of type
DateTime rather than
Why is this raising an exception? That is to do with the implementation of the
StdAdoDelegate class. When the
quartz.jobStore.useProperties configuration value is set to
true it will deliberately fail to write to the job store database any job data that does not use
string for both key and value. Despite this restriction, it still uses binary serialization to store the data after this check (in the form of a
To come back to the original reason for setting this property, the tutorial advises to use it to avoid serializing complex types and getting into versioning issues after type upgrades. I’d contest that this objective could be simply achieved by supporting all the primitive .NET types whose serialization is not likely to change. The change to
StdAdoDelegate would be to perform a type validation of each name/value pair to ensure only simple types are in use in the case of
true and convert it to
System.Collections.Hashtable to allow for changes to the
JobDataMap class to be made in Quartz without causing serialization issues.
Another solution could be to have an XmlAdoDelegate that used XML serialization instead of binary serialization.
Maybe I am missing some extra design constraint here. I’ve posted the issue to GitHub (here) to see if my thoughts can be easily shot down.