Feb 12th, 2008, 02:23 AM
What is the meaning of JobParameters ?
JobParameters is a new class in M4, replacing JobIdentifier from M3. They are semantically different, although it looks like they are used for the same usage: uniquely identifying jobs (in addition to the job name).
My understanding of parameters is to hold external information, as in the following examples:
- the path to a file to be processed
- the name of a JMS queue to receive messages from
- the user name that is to be set as last_modifying_user in impacted business tables
- the processing date (although usually defaulting to today), e.g. like in end of month processing : externalizing it allows to run a job for a specific date at some other date.
- SQL connection info
These parameters are externalized in order to be able to configure them outside of the source code, and even outside of configuration files. Most of these parameters heavily depend on the environment : DEV, TEST, PROD (this is actually the primary usage of these parameters).
When running a job, these parameters do not change from one execution to the other, but do change on some special occasions.
I added some kind of parameters management functionnality in my utilization of spring-batch. These are loaded from database tables, properties files, or system properties specified on command line.
Looking at JobParameters class, its utilization and javadoc, it looks like it should contain some identifier (as were the schedule date or job key fields in M3 JobIdentifierFactory).
This leads to my questions:
- So, what is the exact meaning and usage of this class?
- Shall I write my own JobParametersFactory containing identifying info (but not considered as parameters, in my understanding of the word) such as job key, or can I simply use the default one?
- Shall I copy my parameters into the JobParameters object, so that they are processed by the infrastructure?
Feb 12th, 2008, 11:36 AM
First of all, you're description of Parameters is absolutely correct, but it sounds like the melding of JobParameters with the JobIdentifier is a bit confusing.
1) The essential contract is that, to start a job, you provide the Job and JobParameters, if that Job with the same JobParameters has already been started, we will give back the same JobInstance and tie a new JobExecution to it. If not, we will create a new JobInstance.
2) You can create your own Factory if you have custom properties that you would like to ensure are typesafe, otherwise you could assume them to all be strings. Keep in mind that the biggest advantage to typesafety is being able to query for them from the meta data.
3) I definitely would, since it ensures that the parameters a job instance ran with are persisted for historical reasons. The JobParameters should also be available to the developer via the StepContext.