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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Draft

DreamPearl wants to merge 20 commits into apache:main from DreamPearl:local-transactions

+832 −28

Contributor

DreamPearl commented Nov 20, 2024 •

edited

Loading

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

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

View reviewed changes

Member

astitcher left a comment

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 Outdated Show resolved Hide resolved

cpp/include/proton/target_options.hpp Outdated Show resolved Hide resolved

cpp/include/proton/tracker.hpp Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated

Comment on lines 101 to 62

+              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

Member

astitcher Dec 4, 2024

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

Member

astitcher Dec 18, 2024

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 Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated Show resolved Hide resolved

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

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

DreamPearl force-pushed the local-transactions branch from fa9236d to 347cf6e Compare

December 16, 2024 13:29

astitcher requested changes

View reviewed changes

Member

astitcher left a comment

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 Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated Show resolved Hide resolved

cpp/include/proton/transaction.hpp Outdated

Comment on lines 101 to 62

+              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

Member

astitcher Dec 18, 2024

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 Outdated Show resolved Hide resolved

pematous reviewed

View reviewed changes

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

pematous reviewed

View reviewed changes

cpp/examples/tx_recv.cpp Outdated

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

pematous Jan 21, 2025

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).

pematous Feb 5, 2025 •

edited

Loading

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.

pematous reviewed

View reviewed changes

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

pematous reviewed

View reviewed changes

cpp/examples/tx_send.cpp Show resolved Hide resolved

pematous reviewed

View reviewed changes

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

pematous reviewed

View reviewed changes

cpp/examples/tx_recv.cpp Outdated

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

pematous Jan 24, 2025

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).

DreamPearl force-pushed the local-transactions branch from 4c795ef to eb8afbd Compare

March 17, 2025 17:54

pematous reviewed

View reviewed changes

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

astitcher requested changes

View reviewed changes

Member

astitcher left a comment

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 Show resolved Hide resolved

cpp/examples/tx_recv.cpp Show resolved Hide resolved

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.txn_accept(d);

Member

astitcher Mar 20, 2025

session == d.session()

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

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

cpp/src/proton_bits.hpp Outdated Show resolved Hide resolved

cpp/src/sender_options.cpp Outdated

@@ @@ -66,6 +66,7 @@ class sender_options::impl { @@
                   option<bool> auto_settle;
                   option<source_options> source;
                   option<target_options> target;
+                  option<coordinator_options> coordinator;

Member

astitcher Mar 20, 2025

Not needed if coordinator is a kind of target

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

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

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

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


          WIP: Python example broker work for better transaction support

cefc581

* 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


          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


          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

View reviewed changes

cpp/include/proton/session.hpp

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

Member

astitcher Apr 24, 2025

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

cpp/include/proton/session.hpp

@@ @@ -36,6 +36,7 @@ @@
               struct pn_session_t;
               namespace proton {
+                class transaction_impl;

Member

astitcher Apr 24, 2025

Is this actually needed here?

cpp/include/proton/session.hpp

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

Member

astitcher Apr 24, 2025

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

cpp/include/proton/target_options.hpp Show resolved Hide resolved

cpp/include/proton/session.hpp

Comment on lines +111 to +119

+                  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;

Member

astitcher Apr 24, 2025

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

cpp/src/proactor_container_impl.cpp Show resolved Hide resolved

cpp/src/proactor_container_impl.cpp Show resolved Hide resolved

cpp/examples/tx_send.cpp

+                          msg.id(std::atomic_fetch_add(&unique_id, 1));
+                          msg.body(m);
+                          std::cout << "Sending: " << msg << std::endl;
+                          session.txn_send(sender, msg);

Member

astitcher Apr 24, 2025

I think the API we were aiming for would just use a sender object created from the transactioned session.

cpp/src/session.cpp

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

Member

astitcher Apr 24, 2025

Needs update(t, PN_ACCEPT);

cpp/src/session.cpp

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

Member

astitcher Apr 24, 2025

I think this should be delivery not tracker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet