Hi Raman,
In a nutshell, the main reason for catalog locking is due to unfinished/cancelled processes during the publication.
There are several stages of publication, the are primarily ~ Initiation -> Content Aggregation -> Indexing and Optimization -> Rule Execution (if required) -> Catalog Activation. Then as a seperate process we run the DELETE_OUTDATED_CATALOG process to remove the old SE version.
Sometimes what happens, particularly where people use parallel processing/large amounts of rules and views/have very little memory resource available to the catalog we see failures. Sometimes, people cancel the jobs because they feel publication is not doing anything, i.e. they look in SM37 and just see the job running for what seems like forever. We tend to see this when the publication is on the Rule Execution phase or activation phase. Cancelling the job now leaves the catalog in an inconsistent state which will certainly require manual intervention to 'Cleanup'.
When experiencing issues with the publication you should always analyse the underlying cause, i.e. if the problem seems to be in Rule Execution, maybe 80% of the runtime is spent here, then can you reduce the amount of views used or the amount of contained rules in these views? Would it be easier to limit the access by creating different procurement catalogs with different call structures rather than having lots of views ?1?!
Parallel processing is also an issue occasionally, mostly, it is very useful and improves the runtime, but from time to time especially if your catalog is already problematic, it can make things much worse .... where you had a process which was possibly problematic with sequential processing, now with multiple processes, this is simply going to be a problem!!
Best always to switch this parallel processing off until the catalog is returned to a healthy state again.
I hope this provides some help ...
Regards,
Jason
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.