Something I learned today (the hard way) was about the Task Scheduler and the Sitecore context. The context decides which database to use - core or master.
A little background, I am working on a project where the scheduled tasks of importing content was already set up. Not an excuse, only that for this project, I haven't looked into the scheduled task as of yet.
During a release we saw that a scheduled task actually ran under the core context instead of the usual master context, causing the task to fail. Why all of a sudden did this happen? Our release had nothing to do with the config, nor did it have anything to do with the task scheduler.
What we found out, the legacy code that the task scheduler runs on, was NOT specifying which context to run under. So timing was the fluke during the release. Let me explain. There are config values of course that tells the task scheduler to run under which database. The out of the box is located in Sitecore.config, it was later updated (as best practice dictates), in a patch file.
Looking at the: https://DOMAIN/sitecore/showconfig.aspx it showed both the patch file entry and the out of the box core entry for task settings. The core one was set to run every 10 minutes and the custom one (master) was set to run every 5 minutes. Timing was why the task failed because the context switcher, switched to core at some point, and our code never set it back to the intended master context. BIG PROBLEM!
So after some research we found a great article on Google from kiranpatils on (https://sitecorebasics.wordpress.com/2014/08/09/scheduled-task-basics/) that stated the best practice.
LESSON LEARNED: Always wrap your tasks calls with the intended context with the using command.
Once we wrapped the code, all was well and life was once again delightful!
No comments:
Post a Comment