Fix incomplete transaction commit when thread is shutdown ungracefully

[intale]

Problem description

Running transactions may suddenly commit when the thread it is running from is force-shutdown.

Steps to reproduce

Refer to the newly added test case

Solution

To fix this we have to additionally check the thread status in ensure block and rollback in case we've been interrupted.

[intale]

It seems I need to look into the behaviour of truffleruby as, it seems, it requires special attention

[larskanis]

I added two more commits. Are they OK from your point of view?

[intale]

I added two more commits. Are they OK from your point of view?

I have a concern regarding rescue Exception => error case. Previously it was rescue => rollback => re-raise which was logical, but now it is rescue => re-raise => rollback. While I can't provide any edge case where this sequence change may result in any side effect - it may depend on a different ruby implementation, thus introducing some different behaviour than intended. What do you think? Do you have something in mind that could potentially affect on the final result? Otherwise looks good to me - you caught this randomly failing issue with the test I provided and replaced pg_sleep with sleep.
Imho, I would keep the implementation explicit for each case like it was before as it is more straightforward from my point of view.

[larskanis]

I like the new ensure based approach more, since rollback in rescue makes it more cluttered. This is because rescue is not called in two cases: when the yield is aborted by break and when the thread is killed. But all cases are caught in the ensure branch. So it's more natural and clearer to me to handle all cases of commit or rollback there. The ruby language definition of rescue/ensure is old and well described - it's not an edge case.

[intale]

The ruby language definition of rescue/ensure is old and well described - it's not an edge case.

It is. Cool. I just tried to be paranoid about the potential behaviour. I don't have any more remarks.

[larskanis]

Thank you @intale for raising this issue and providing fix and test!