When a price list import is executed in the back office to update product prices, "price change events" are created in the database. After the import, a separate job ProcessProductPriceRefresh must be executed to process the created price change events and do further things like CacheRefresh etc. The job ProcessProductPriceRefresh has a job configuration named Cleanup events. Depending on that configuration (
false), the processed price change events are deleted (Cleanup events =
true) or remain in the database (Cleanup events =
false/missing). The default value is
In order to reduce the number of events to process and also to ensure that the events are processed only once (for option Cleanup events =
false), this job only processes events that are created within a certain time frame - from the last run of this job until now.
Since the job ProcessProductPriceRefresh (which consumes the events) is independent from the price list import which creates the events, it could be that both processes run simultaneously. In this case, events are created within the time frame of the current run in which they are to be processed. However, they are not because of parallel execution. This leads to an accumulation of unprocessed price change events in the database.
This occurred in both modes (Cleanup events =
The job has been changed again in ICM 126.96.36.199-LTS. See linked migration guide in next paragraph "References".
true - default)
In order to fix that issue, the behavior of the job ProcessProductPriceRefresh was changed for the option (Cleanup events =
Running the job with Cleanup events =
true usually means that afterwards all processed price change events are removed and the database table should be empty. So there is no need to reduce the number of events that are processed by a time frame. Therefore this date check has been removed. As a result, the price change events created from the price list import during a parallel execution remain in the database after the current run of the job ProcessProductPriceRefresh. They will then be processed with the next run. Since the mode "Cleanup events =
true" is the default option, this fix will cover most cases. There is no migration necessary. However, there could be a lot of leftover (outdated) price change events that the job has to process, which might increase the execution time of the job.
Depending on the amount of outdated price change events that might have been left over, it could be necessary to remove the event objects manually. If the job gets executed immediately after the migration it might run into memory problems.
The following SQL statement can be used to clean up outdated product price change events:
DELETE from PRODUCTPRICECHANGEEVENT where creationdate < 'DD.MM.YY'; commit; // if necessary
'DD.MM.YY' (example: '01.11.20') should be a date in the recent past, e.g. one week ago. It does not matter if some of the outdated entries will be left. They are automatically cleaned up during the next run. When the biggest amount of legacy data was removed, the job will continue regularly.
The described process of deleting outdated items will automatically be done by the job from ICM 188.8.131.52-LTS on.
The behavior for the second option (Cleanup events =
false) remains unchanged.
This means there could still be unprocessed price change events. Therefore, Intershop does not recommend using this option.