XMLSchedulingDataProcessorPlugin incompatible with StdAdoDelegate when useProperties=true #44

Closed
Jawvig opened this Issue May 23, 2012 · 4 comments

Comments

Projects
None yet
3 participants
@Jawvig

Jawvig commented May 23, 2012

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 in tutorial 9, I'm instructing the job store to persist job parameters in plain text rather than BLOBs, using the configuration:

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 string.

This raising an exception due to 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 NameValueCollection).

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 quartz.jobStore.useProperties being 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?

@skurdiukov

This comment has been minimized.

Show comment
Hide comment
@skurdiukov

skurdiukov Jun 1, 2012

Contributor

I think having ability to choose serializer for JobDataMap is a good option.

Contributor

skurdiukov commented Jun 1, 2012

I think having ability to choose serializer for JobDataMap is a good option.

@skurdiukov

This comment has been minimized.

Show comment
Hide comment
@skurdiukov

skurdiukov Jun 2, 2012

Contributor

I found that you can use property "quartz.serializer.type" and define any custom serializer that implement IObjectSerializer interface.

Contributor

skurdiukov commented Jun 2, 2012

I found that you can use property "quartz.serializer.type" and define any custom serializer that implement IObjectSerializer interface.

@lahma

This comment has been minimized.

Show comment
Hide comment
@lahma

lahma Jun 23, 2012

Member

I agree that some relaxations could be made for the basic types as their serialization is well tested and known, the problem just is that serialized implementation is a NameValueCollection that cannot have any other types.

I think that UseProperties can well be false if one acknowledges the possible issues with serialization if non-primitive types are being used.

Member

lahma commented Jun 23, 2012

I agree that some relaxations could be made for the basic types as their serialization is well tested and known, the problem just is that serialized implementation is a NameValueCollection that cannot have any other types.

I think that UseProperties can well be false if one acknowledges the possible issues with serialization if non-primitive types are being used.

@lahma lahma added this to the 2.3 milestone Jul 19, 2014

@lahma lahma removed this from the 2.3 milestone Nov 8, 2014

@lahma lahma added this to the 2.6 milestone Jul 25, 2017

lahma added a commit that referenced this issue Jul 25, 2017

@lahma lahma closed this in b43a56a Jul 25, 2017

@lahma

This comment has been minimized.

Show comment
Hide comment
@lahma

lahma Jul 25, 2017

Member

Well that didn't take long. Now binary serialization is used for job data map that is detected to be from FileScanJob. Kind of a hack, but gets the job done without too much worries.

Member

lahma commented Jul 25, 2017

Well that didn't take long. Now binary serialization is used for job data map that is detected to be from FileScanJob. Kind of a hack, but gets the job done without too much worries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment