I have been tracking down an issue with the echo module d.o/project/echo failing to return any content. It turns out in our installation that this is being caused by commerce opening a transaction for pessimistic locking which causes echo to fail. This only happens when I have something in my cart.
The cause seems to be commerce_cart_menu_item_title which loads the order if I have one in cart mode. The order loaded is cached along with the transaction. I can't see any way to stop this happening as any order load always assumes pessimistic locking. I can work around it by reseting the entity cache for commerce orders as this frees the transaction. It seems a little over the top to hold a transaction just to update the menu title for a cart link.
Comments
Comment #1
rszrama commentedI'm not entirely clear on the problem here - it should only prevent additional loads on the Order table, no? I don't think it should be holding up any other database transactions.
Comment #2
applicity_sam commentedRyan unfortunately not. The echo module is used to wrap content in a theme for outputting onto an email. The flow for echo is that it sets an entry into the cache via cache_set. It then makes a request back to the same server using drupal_http_request, at this point the value is not in the cache so the echo process fails. I guess the question is why we are holding a transaction open for the order when we have simply used it to set the title of the cart. I have been able to work round it for the moment by clearing the entity cache for the order in question. This causes the transaction to go out of scope and be cleared.
Comment #3
matt v. commentedFor what it's worth, there's more background about the issue in Echo in #1448278: Access denied in the email sent.
I'm experiencing the problem with Echo sending out emails with "Access Denied" text primarily when processing queues. One queue for renewing site subscriptions (which are handled by Commerce) seems to be causing problems for another queue that is sending emails. If I run the two queues concurrently, I get the "Access Denied" message embedded in most of the outgoing emails, but if I process the queues separately the emails go out fine. The renewal queue also sends out some "Access Denied" emails of its own, when renewals fail.
I'm a little unclear on the details of applicity_sam's workaround. Until I can work out the details of a more robust fix, I'm planning on running the queues separately, so at least they don't interfere with each other.
Comment #4
mglamanReferenced issue in #3 shows its bug in other project.