PROTON-1442: [Cpp] Support for local transactions #437

DreamPearl · 2024-11-20T08:57:17Z

PROTON-1442

AMQP Transaction Sequence:

Declare transaction:

Client establishes link to Broker (Transaction resource) to target with transaction coordinator type (usual types are sender/receiver) (ATTACH frame)
Client (Transaction Controller) sends a special message to that link to create transaction (TRANSFER frame)
Broker returns a disposition with the transaction id (DISPOSITION frame)

Send Message in the transaction:

Client sends a message to the broker with transaction id in the state field.

Commit/Abort

astitcher

I've taken a fairly thorough look. If you have any questions about these review items we should discuss further.

cpp/include/proton/container.hpp

cpp/include/proton/target_options.hpp

cpp/include/proton/tracker.hpp

cpp/include/proton/transaction.hpp

astitcher · 2024-12-04T20:37:59Z

cpp/include/proton/transaction.hpp

+class
+PN_CPP_CLASS_EXTERN transaction_handler {
+  public:
+    PN_CPP_EXTERN virtual ~transaction_handler();
+
+    /// Called when a local transaction is declared.
+    PN_CPP_EXTERN virtual void on_transaction_declared(transaction);
+
+    /// Called when a local transaction is discharged successfully.
+    PN_CPP_EXTERN virtual void on_transaction_committed(transaction);
+
+    /// Called when a local transaction is discharged unsuccessfully (aborted).
+    PN_CPP_EXTERN virtual void on_transaction_aborted(transaction);
+
+    /// Called when a local transaction declare fails.
+    PN_CPP_EXTERN virtual void on_transaction_declare_failed(transaction);
+
+    /// Called when the commit of a local transaction fails.
+    PN_CPP_EXTERN virtual void on_transaction_commit_failed(transaction);
+};
+
+} // namespace proton
+


I think this should be in a different header file like message and messaging_handler

So if the API makes transactions hidden in a session then these callbacks either go away or instead become session callbacks: on_session_transaction_committed(session&), etc. I think transaction_declared() goes away entirely and it's purpose is now another use for on_session_open(session&). on_.._declare_failed should be handled by the on_session_error(session&).

cpp/include/proton/transaction.hpp

cpp/examples/tx_recv.cpp

astitcher

I've not reviewed this comprehensively, but I think I'm now very much leaning towards not making the transaction class visible to the API user at all and having the transaction methods on the session. This is essentially the API in JMS and CMS.

cpp/include/proton/transaction.hpp

astitcher · 2024-12-18T23:10:52Z

cpp/include/proton/transaction.hpp

+class
+PN_CPP_CLASS_EXTERN transaction_handler {
+  public:
+    PN_CPP_EXTERN virtual ~transaction_handler();
+
+    /// Called when a local transaction is declared.
+    PN_CPP_EXTERN virtual void on_transaction_declared(transaction);
+
+    /// Called when a local transaction is discharged successfully.
+    PN_CPP_EXTERN virtual void on_transaction_committed(transaction);
+
+    /// Called when a local transaction is discharged unsuccessfully (aborted).
+    PN_CPP_EXTERN virtual void on_transaction_aborted(transaction);
+
+    /// Called when a local transaction declare fails.
+    PN_CPP_EXTERN virtual void on_transaction_declare_failed(transaction);
+
+    /// Called when the commit of a local transaction fails.
+    PN_CPP_EXTERN virtual void on_transaction_commit_failed(transaction);
+};
+
+} // namespace proton
+


So if the API makes transactions hidden in a session then these callbacks either go away or instead become session callbacks: on_session_transaction_committed(session&), etc. I think transaction_declared() goes away entirely and it's purpose is now another use for on_session_open(session&). on_.._declare_failed should be handled by the on_session_error(session&).

cpp/include/proton/transfer.hpp

cpp/examples/tx_send.cpp

pematous · 2025-01-21T15:35:45Z

cpp/examples/tx_recv.cpp

+        transaction.accept(d);
+        current_batch += 1;
+        if(current_batch == batch_size) {
+            transaction = proton::transaction(); // null


I believe we should do rather commit here, that way it works as expected and the receiver is closed after expected number of messages received (with the current implementation it's not).

I believe we should do rather commit here, that way it works as expected and the receiver is closed after expected number of messages received (with the current implementation it's not).

above mentioned change:

- transaction = proton::transaction(); // null + transaction.commit();

works as expected (against Artemis broker) when using multicast. However, when a pre-defined anycast queue is used, the commit() call ends with client segmentation fault.

cpp/examples/tx_recv.cpp

cpp/examples/tx_send.cpp

pematous · 2025-01-24T10:16:46Z

cpp/examples/tx_recv.cpp

+
+    void on_message(proton::delivery &d, proton::message &msg) override {
+        std::cout<<"# MESSAGE: " << msg.id() <<": "  << msg.body() << std::endl;
+        transaction.accept(d);


btw. I'm thinking if transaction.accept() does actually have any effect? I mean, when I comment it out, the program behaves the same. btw. is this transaction accept any different from delivery accept? looks both settles the messages related to the delivery.

Does explicit delivery settling play role in transaction mode? or are they mutually exclusive and only commits and aborts applies? Can ie. single message in transaction be rejected while other messages accepted?

I tried to accept / reject the delivery and it seems to have no effect in transaction mode (while in python, doing so makes the messages to be threat outside of the transaction, just like a normal messages, https://issues.redhat.com/browse/ENTMQCL-513).

cpp/src/messaging_adapter.cpp

astitcher

Lopts of detailed comments here, but the main change I'd like to see is either make coordinator a subclass of target or fold it into a simple boolean option of target.

cpp/examples/tx_recv.cpp

cpp/examples/tx_send.cpp

cpp/src/proton_bits.hpp

cpp/src/sender_options.cpp

cpp/src/transaction.cpp

* Added an extra handler to the python binding so that we can handle transactioned dispositions

* Modified the Python example broker so that it understands transaction requests, prints some useful output about what is happening, but doesn't honor the transaction semantics. It will queue up transactioned messages immediately and also doesn't correctly handle outgoing message releases (but it doesn't for non-transactioned messages either

* Make it compile * Make it fit the existing software structure better

astitcher · 2025-04-24T13:51:08Z

cpp/include/proton/session.hpp

+
+    private:
+    // clean up txn internally
+    void txn_delete();


I'd be very surprised if this is needed here - I'd think it could only be called from the impl class

astitcher · 2025-04-24T13:51:24Z

cpp/include/proton/session.hpp

@@ -36,6 +36,7 @@
 struct pn_session_t;

 namespace proton {
+  class transaction_impl;


Is this actually needed here?

transaction_impl is pirely internal and should not be in an externally visible header file

astitcher · 2025-04-24T13:52:02Z

cpp/include/proton/session.hpp

    /// @cond INTERNAL
  friend class internal::factory<session>;
  friend class session_iterator;
+  friend class transaction_impl;


I'd think it's more likely that transaction_impl needs to a friend of session_impl

cpp/include/proton/target_options.hpp

astitcher · 2025-04-24T13:57:23Z

cpp/include/proton/session.hpp

+    PN_CPP_EXTERN bool txn_is_empty();
+    PN_CPP_EXTERN bool txn_is_declared();
+    PN_CPP_EXTERN void txn_commit();
+    PN_CPP_EXTERN void txn_abort();
+    PN_CPP_EXTERN void txn_declare();
+    PN_CPP_EXTERN void txn_handle_outcome(proton::tracker);
+    PN_CPP_EXTERN proton::tracker txn_send(proton::sender s, proton::message msg);
+    PN_CPP_EXTERN void txn_accept(delivery &t);
+    PN_CPP_EXTERN proton::connection txn_connection() const;


Aren't these just internal functions? They should only be needed inside session_impl

cpp/src/proactor_container_impl.cpp

cpp/examples/tx_send.cpp

astitcher · 2025-04-24T14:42:21Z

cpp/src/session.cpp

+}
+
+void transaction_impl::accept(delivery &t) {
+    t.settle();


Needs update(t, PN_ACCEPT);

astitcher · 2025-04-24T14:44:18Z

cpp/src/session.cpp

+    t.settle();
+}
+
+void transaction_impl::update(tracker &t, uint64_t state) {


I think this should be delivery not tracker

astitcher

First batch of comments

astitcher · 2025-08-28T15:59:23Z

cpp/examples/tx_recv.cpp

+
+    void on_message(proton::delivery &d, proton::message &msg) override {
+        std::cout<<"# MESSAGE: " << msg.id() <<": "  << msg.body() << std::endl;
+        session.transaction_accept(d);


should just be accept now as this is already a transactioned session

astitcher · 2025-08-28T16:00:10Z

cpp/examples/tx_recv.cpp

+        session.transaction_accept(d);
+        current_batch += 1;
+        if(current_batch == batch_size) {
+        }


Need to commit or abort transaction here

astitcher · 2025-08-28T16:08:10Z

cpp/include/proton/session.hpp

@@ -36,6 +36,7 @@
 struct pn_session_t;

 namespace proton {
+  class transaction_impl;


transaction_impl is pirely internal and should not be in an externally visible header file

astitcher · 2025-08-28T16:10:25Z

cpp/include/proton/session.hpp

+    PN_CPP_EXTERN void transaction_commit();
+    PN_CPP_EXTERN void transaction_abort();
+    PN_CPP_EXTERN void transaction_declare();
+    PN_CPP_EXTERN void transaction_handle_outcome(proton::tracker);
+    PN_CPP_EXTERN void attach_txn_id(proton::tracker t);
+    PN_CPP_EXTERN void transaction_accept(delivery &t);
+    PN_CPP_EXTERN proton::connection transaction_connection() const;


These are all internal functions and shouldn't be in the visible header file

astitcher · 2025-08-28T16:11:30Z

cpp/include/proton/session.hpp

@@ -105,14 +106,31 @@ PN_CPP_CLASS_EXTERN session : public internal::object<pn_session_t>, public endp
    /// Get user data from this session.
    PN_CPP_EXTERN void* user_data() const;

+    PN_CPP_EXTERN void declare_transaction(proton::transaction_handler &handler, bool settle_before_discharge = false);


I think this is meant to be called transaction_declare(...) once the internal function below is removed

DreamPearl marked this pull request as draft November 20, 2024 08:57

DreamPearl force-pushed the local-transactions branch 2 times, most recently from 74818fc to eb4514b Compare November 21, 2024 18:28

DreamPearl force-pushed the local-transactions branch from 3e96834 to fa9236d Compare December 3, 2024 12:56

astitcher requested changes Dec 4, 2024

View reviewed changes

DreamPearl force-pushed the local-transactions branch from fa9236d to 347cf6e Compare December 16, 2024 13:29

astitcher requested changes Dec 18, 2024

View reviewed changes

pematous reviewed Jan 21, 2025

View reviewed changes

cpp/examples/tx_send.cpp Outdated Show resolved Hide resolved

pematous reviewed Jan 21, 2025

View reviewed changes

cpp/examples/tx_recv.cpp Outdated Show resolved Hide resolved

pematous reviewed Jan 24, 2025

View reviewed changes

cpp/examples/tx_send.cpp Show resolved Hide resolved

pematous reviewed Jan 24, 2025

View reviewed changes

cpp/examples/tx_send.cpp Outdated Show resolved Hide resolved

pematous reviewed Jan 24, 2025

View reviewed changes

DreamPearl force-pushed the local-transactions branch from 4c795ef to eb8afbd Compare March 17, 2025 17:54

pematous reviewed Mar 18, 2025

View reviewed changes

cpp/src/messaging_adapter.cpp Outdated Show resolved Hide resolved

astitcher requested changes Mar 20, 2025

View reviewed changes

DreamPearl force-pushed the local-transactions branch from eb8afbd to 4c795ef Compare March 26, 2025 05:04

astitcher and others added 13 commits April 14, 2025 22:17

WIP: Python work for better transaction support

d6a9844

* Added an extra handler to the python binding so that we can handle transactioned dispositions

Implement local transactions

81f821c

WIP: Fix up to transactions work:

5d3984c

* Make it compile * Make it fit the existing software structure better

Make example compile

abada2f

Add txn id in disposition frame bits

b459f27

Add transaction commit and abort functionalities

bf9f15e

Add tx_recv file

547a872

Move the transaction_impl class logic to cpp file

9e3594b

Has errors

4bd0cd2

Add coordinator class

9787363

Allow multiple transactions but one at a time

daf1160

Move txn_impl into CPP file

4c462b6

DreamPearl added 4 commits April 14, 2025 22:17

Clean up the code

ac01d04

Removed coordinator class and improved STATES handling.

c7405c7

Rebased and fix seg fault

3834f4b

Add tx_recv

6fd1434

DreamPearl force-pushed the local-transactions branch from 578445f to 6fd1434 Compare April 17, 2025 12:39

DreamPearl added 3 commits April 21, 2025 19:10

Some more clean up and improvements

0e4b3b4

Renamed transaction files to transaction_handler

37379aa

Replaced static int to std::atomic<int>

fe1a543

astitcher reviewed Apr 24, 2025

View reviewed changes

DreamPearl and others added 8 commits May 29, 2025 10:46

Renaming and code clean

33516a4

Naming and split open sender [Not working]

18b9448

Fix core dump in tx_send

0a18b3a

Change API to use sender send instead of session:transaction_send.

8c6e263

Accept and update takes transfer now instead of delivery and tracker.

6cfb78e

Rename transaction_impl::send to attach_txn_id

7321c0e

Add first version of test file

8c13443

Change to let the library handle update() for transactional disposition

7860057

astitcher reviewed Aug 28, 2025

View reviewed changes

PROTON-1442: [Cpp] Support for local transactions #437

Are you sure you want to change the base?

PROTON-1442: [Cpp] Support for local transactions #437

Uh oh!

Conversation

DreamPearl commented Nov 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

astitcher left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

astitcher left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pematous Feb 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

astitcher left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

astitcher left a comment

Choose a reason for hiding this comment

Uh oh!

DreamPearl commented Nov 20, 2024 •

edited

Loading

pematous Feb 5, 2025 •

edited

Loading