shopsys
shopsys copied to clipboard
shopsys
Recalculating products availability and prices immediately instead of on finish request
When programmer needs mass create/edit a lot of products (eg. during import at cron module), recalculating by schedulers and clearing internal their caches is a painful - It is easily forgetable and unnecessary.
Price recalculation does not use native query and can be run immediately - There is not any reason why this calling waits on finish request event.
Availability recalculation does not use native query too, but here is one exception - variants. Recalculation of variants calls ProductVisibilityFacade::refreshProductsVisibilityForMarked() and this could cause problem in the future, when some action in background marks a lot of products to availability recalculation and somebody create order at front-end. Order creation calls recalculate availability -> it could take a lot of time.
Because there is problem with variants availabilty, this merge request maybe is not ready to merge, but for me usecase is sufficient solution and problem with executing native query in request is solved by EntityManager::refresh().
Also mentioned in: https://git.shopsys-framework.com/shopsys/shopsys-framework/merge_requests/6
This issue has been automatically marked as stale because there was no activity within the last 4 months (and it is quite a long time). It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because there was no activity within the last 4 months (and it is quite a long time). It will be closed if no further activity occurs. Thank you for your contributions.
seems to me we are able to solve the problem elegantly using RabbitMQ after https://github.com/shopsys/shopsys/pull/1228 is finished
This issue has been automatically marked as stale because there was no activity within the last 4 months (and it is quite a long time). It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because there was no activity within the last 4 months (and it is quite a long time). It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because there was no acivity within the last half a year.
This issue has been automatically marked as stale because there was no activity within the last 4 months (and it is quite a long time). It will be closed if no further activity occurs. Thank you for your contributions.
Is there any update or progress? We had 23 internal 500 errors because of it (Deadlock), and manually extended and removed immediate recalculations in our new release. 23 of 60 orders was not processed, because of this error.
Hi, yes, disabling recalculation during requests is the way how to solve this quickly. However, this solution has delayed (up to 5 minutes) hiding on sold-out products. This can be a problem for some e-shops. For those that need it, I recommend manually checking for out-of-stock, updating stock quantity and hiding products outside master transaction (https://github.com/shopsys/shopsys/blob/master/packages/framework/src/Component/HttpFoundation/TransactionalMasterRequestListener.php) Updating 1 row outside transaction can't cause deadlock. Another tip for better performance is to do short transactions as much as possible, because a single row update can be blocked by a long transaction in background (cron) with the same updated row - do small transactions eq. during transfers from ERP.
All solutions cause a big BC-break for the behavior of order process and we will work on this on ShopSys Framework version 10. And when will version 10 be released? We want to create a new roadmap in early 2022 year and this will be included.
