mysql icon indicating copy to clipboard operation
mysql copied to clipboard

Clearing connection queue? (conn._protocol._queue)

Open ZackMeadows opened this issue 5 years ago • 3 comments

Are there any safer / recommended ways to clear out the connection queue of queries to prevent them from being executed? I discovered I could manually set connection._protocol._queue to an empty array, and that would accomplish my goal ... but it feels dirty.

Any other means, or is clearing out _queue not as dangerous as it seems?

ZackMeadows avatar May 07 '19 13:05 ZackMeadows

Both yes and no, but to get an appropriate answer, perhaps would it be possible to describe your use case as to why you are trying to clear the queue?

dougwilson avatar May 07 '19 14:05 dougwilson

I've got a bunch of models in our application backend, wrapped in a .beginTransaction(). Depending on the complexity of the action, they can get pretty long and heavy. A bunch of stored procedure calls are queued up through a whole heap of promise arrays, nested inside a .then() of another Promise.all, nested in a promise, nested in another promise, etc. I've found that in some cases, when one of these queries fails, the Promise.all().catch() is triggered immediately by a reject and moves on to the main wrapper .catch() right away, while some sibling promises are still waiting to be handled.

The main catch calls a connection.rollback() to get rid of anything that happened in this transaction, and then goes about creating some error logs before committing again. The remaining queries then finish up their sql process AFTER the connection.rollback(), and get themselves commit with the errors. Boo! When I set connection._protocol_queue = [] before connection.rollback(), those promises don't come through anymore! I'm worried that might have some adverse effects, though.

ZackMeadows avatar May 07 '19 14:05 ZackMeadows

Ah, I see. So what is happening is that in your code you end up in a condition where you expect to be in a transaction, but there is a condition that triggers a rollback of said transaction, but nothing in the code to prevent those queries from actually getting run on the connection after the rollback occurs, so they are all auto committed, is that right?

Unless I'm missing something here I cannot see how clearing the (empty) queue would prevent the queries from still running after the rollback, though. It would break any currently executing sequence though since it is tracked by being at index zero in a few places.

Would it be possible to provide code that demonstrates what you are seeing here so I can use that to better understand how to solve this issue?

dougwilson avatar Oct 04 '19 06:10 dougwilson