Singel threaded queue

Jaise James

Reputable Poster
All,
if people are running jobs in single threaded queues any more. Oracle has time and again mentioned that we can run jobs like post(R09801) in non-single threaded queue. Has anyone seen any issues with this configuration
 
The R09801 has been multi-threaded queue capable since XE with some caveats. The XE requirement was to use data selection to assure that the R09801 didn't select the same source data. This was done by using batch type and/or user id. At some point they enhanced the R09801 to skip over batches marked as "in use". Which should mean that you can run as many copies of R09801 concurrently as you want with whatever data selection as the first job to get a batch will mark it in use and other posting jobs will skip over the batch if it ends up in the scope of their data selections.

With all that said only about a third of my sites run the job in a multi-threaded queue. With a single threaded queue people feel comfortable that there is no chance for issue. Where I have sites running in multi-threaded queues we have respected the current Oracle recommendation to have separate versions for each batch type. (Which is just the XE recommendation carried forward to today)

I do question why they recommend the need for data selection on batch type when they say that the R09801 now skips over batches that are marked in use (by other running posts). It would be nice to have a simple yes from them. Having the data selection is sensible from a performance standpoint but is it really needed to assure that two jobs don't try to post the same information? If the batch in use functionality works as they say it does there should be no need to use data selection to assure integrity.

So basically I haven't seen any issues with multi-threaded configuration but we are still applying cautious data selection to narrow down what each posting job can see.
 
Justin,

Thanks for your detailed explanation. I do have one questions. Do you run all the Post jobs using Scheduler or Let user submit them or mixer of both.

We run majority of our post job via Scheduler, but do allow end users to submit them manually as well. With this requirement, do you think, there can still be chance of manual job colliding with scheduled job
 
I had a fairly large customer that ran scheduled sweeper post job versions (different versions for each batch type)run hourly to post any approved batches. Certain GL users had the ability to do a post a by batch , and at times their submissions would "collide" with the scheduled version that was trying to post the same batch. But who ever got to it first would put the batch in use and the other would not be able to post it. So occasionally the user would get a PDF output that had a message on it saying their batch could not be posted as it was in use. (I do not remember the exact output on the R09801), but we just had to train / inform the users that this was normal and to check on the status of the batch later and confirmed that it showed as posted.

This was on an older release that too (8.9 ) and they had no issues , so I can only imagine that it still works well if not better now on the latest releases. You should be able to run a few tests in your non prod environment to examine the exact behavior and also validate that there are no data integrity issues.
 
Back
Top