Many of our API's would benefit if we designed to use JTA transactions API

[lesv]

We should consider this for Spanner, PubSub, and other API's, however, it might need updating the product API's to support this, so it may be a moot ask.

RayT recently wrote wrote:

That's a good start. In short, a hook would at least have begin transaction, commit, and abort/recover semantics.

To be true distributed transactional, it'll need a XA resource adapter.

Otherwise, another pattern would be temporarily writing the pub/sub message into a transactional store (e.g., via JDBC into a database), and have another background process that can guarantee delivery and do all the retries, etc.

That being said, how does Google deal w/ similar cases? Perhaps we recommend people not to do this (that's my guess), but we need to recommend alternatives.

[saturnism]

If not XA, start w/ just JTA

[lesv]

I sent an email about this recommending JTA with some specs.

[lesv]

I know of two customers who would like this - who asked in the last 30 days.

[garrettjonesgoogle]

This has been added to our feature backlog: https://github.com/GoogleCloudPlatform/google-cloud-java/wiki/Feature-backlog . This issue will be closed but is linked in the backlog and can continue to be used for comment and discussion.

[vkedia]

@saturnism I was looking at the JTA transaction interface. There are methods there which are needed for supporting distributed transactions which Spanner does not support.

Does it still make sense to implement this interface and just implement the commit and rollback functionality and throw UnsupportedException for other methods? Are there other databases which do this? Without XA support, is implementing this still useful?