Multiple Instance Usage - Best Practices

[gsbrown]

I've run into a situation where I need a job that can be called at many different times by many different control jobs. The chance that the job could be called at the same time by two different control jobs is VERY likely.

Therefore, I looked into making the job a multiple instance job. This sounded like a good idea until I realized that every instance has to have a unique invocation id and the jobs do not clean themselves up after running. I could make this work by having the control jobs create a numeric datetime string as the invocation id, but how do you handle the cleanup?

Would like to hear tips about ultilizing multiple instance the best way.

thanks,
Greg

[kduke]

You can set the log to clear itself after every 3 or 4 runs or whatever number you want. Clearing the instance ids is another problem.

[asitagrawal]

Hi,

Can u plz exzplain " jobs do not clean themselves up after running" ??

May be I can then help...

[ray.wurlod]

Multi-instance jobs are intended for almost precisely the situation you're in, perhaps also for continuously-running jobs or jobs that use the RTI components (and might be invoked from lots of places).

I agree that non-selective log purge is an issue, but you can code around this or just rely upon auto-purge based on a run count.

[JoshGeorge]

I could make this work by having the control jobs create a numeric datetime string as the invocation id, but how do you handle the cleanup?

If you make your control job<b>s</b> pass an invocation id which is specific to it (ie. same) every time to invoke the job which is set to 'reset and run if required', you can over write on the instances and avoid instance ids piling up on timestamps.
Note: This is under the assumption that same control job does not call the same job instance multiple times at the same time.