(Official) access to TransactionCoordinatorClient

[TomaszGaweda]

Hi!

Greatings from Hazelcast! We are now integrating Hazelcast with Pulsar and so far it's a great journey!

One thing that stands out as not-quite-great is our ability for commit or abort a transaction by ID itself. We snapshot transaction IDs (including TxnID), in case of failures we want to be able to reliably commit or abort transactions in progress. Right now it's impossible to do officially.

I can do following:

		PulsarClientImpl impl = (PulsarClientImpl) client;
        TransactionCoordinatorClient tcClient = impl.getTcClient();
        if (commit) {
            try {
                tcClient.commit(transactionId.txId);
            } catch (TransactionCoordinatorClientException e) {
                throw new RuntimeException(e);
            }
        } else {
            try {
                tcClient.abort(transactionId.txId);
            } catch (TransactionCoordinatorClientException e) {
                throw new RuntimeException(e);
            }
        }

and Flink was also doing this.

However, it relies on casting to impl classes and using interface marked as PrivateApi. Is there a possibility, that such functionality could be released as a part of official API? Even if hidden under some accessors (e.g. TransactionCoordinator.getFor(client) + interface not private api; this will make it invisible to normal users and won't pollute main API).
Thanks in advance for reading my suggestion and I'll be happy to help with this if green lighted by Pulsar Team.

[TomaszGaweda]

PoC of changes needed: https://github.com/TomaszGaweda/pulsar/tree/move-TransactionCoordinatorClient-to-public-api
Not making PR until there is some more agreement on this topic from maintainers :)

[merlimat]

@TomaszGaweda For v5 API, I was thinking we could expose a way to serialize/deserialize the id of the transactions, so that you could be able to "restore" an existing txn and commit/abort.

The only concern is around what could effectively become a "multi-client" instance transaction since, even if ones does not abuse the API, it could be impossible to know if the previous client instance is still running. Need to put some more thoughts on this.

[merlimat]

The question is also how to clearly define the semantic for this multi-client transactions: eg: different clients publishing/acking within the context of same transaction.