On Wed, 22 Jan 2020 at 09:02, Hamid Akhtar <hamid.akh...@gmail.com> wrote: > > At this stage, I'm not sure of the scale of changes this will require, > however, I wanted to get an understanding and consensus on whether (a) this > is something we should work on, and (b) whether an approach to implementing a > timeout makes sense. > > Please feel free to share your thoughts here.
The intended use case of two phase transactions is ensuring atomic durability of transactions across multiple database systems. This necessarily means that there needs to be a failure tolerant agent that ensures there is consensus about the status of the transaction and then executes that consensus across all systems. In other words, there needs to be a transaction manager for prepared statements to actually fulfil their purpose. Therefore I think that unilaterally timing out prepared statements is just shifting the consequences of a broken client from availability to durability. But if durability was never a concern, why is the client even using prepared statements? Citing the documentation: > PREPARE TRANSACTION is not intended for use in applications or interactive > sessions. Its purpose is to allow an external transaction manager to perform > atomic global transactions across multiple databases or other transactional > resources. Unless you're writing a transaction manager, you probably > shouldn't be using PREPARE TRANSACTION. Regards, Ants Aasma