way transactions.
>
> On the downside, an explicit prepare RPC would have a performance hit on
> the happy path in every single transaction.
>
> -Artem
>
> On Tue, Feb 6, 2024 at 7:35 PM Rowland Smith wrote:
>
> > Hi Artem,
> >
> > I am not sure what you me
antages such as
> elimination the needs for monitoring, tooling or providing additional
> guarantees. Let me know if you think of a guarantee that prepare RPC would
> provide.
>
> -Artem
>
> On Mon, Feb 5, 2024 at 6:22 PM Rowland Smith wrote:
>
> > Hi Artem,
> >
>
separate store, say in a compacted topic. This way, the
> core Kafka protocol could be decoupled from specific implementations (and
> extra performance requirements that a specific implementation may impose)
> and serve as a foundation for multiple implementations.
>
> -Artem
>
> On
s.
>
> -Artem
>
> On Thu, Jan 4, 2024 at 6:14 PM Rowland Smith wrote:
>
> > It is probably me. I copied the original message subject into a new
> email.
> > Perhaps that is not enough to link them.
> >
> > It was not my understanding from reading KIP-939 that
I would like permission to contribute to Kafka. I have created Wiki and
Jira ID's 'rowls'.
I will be working with a KIP for XA support.
--
*Rowland E. Smith*
P: (862) 260-4163
M: (201) 396-3842
wanted to
> clarify what the current KIP is proposing.
>
> Thanks,
> Justine
>
> On Wed, Jan 3, 2024 at 7:49 PM Rowland Smith wrote:
>
> > Hi Artem,
> >
> > I saw your response in the thread I started discussing Kafka distributed
> > transaction suppo
Hi Artem,
I saw your response in the thread I started discussing Kafka distributed
transaction support and the XA interface. I would like to work with you to
add XA support to Kafka on top of the excellent foundational work that you
have started with KIP-939. I agree that explicit XA support
Hi All,
I am new to the Kafka developer community. After learning more about
Kafka's transactional capabilities recently, I became interested in
exploring what would be required to provide support for the XA interface
specified in the X/ Open Distributed Processing Model in the Kafka producer