COSTRANSACTIONS_COORDINATOR(3erl)

💖 NAME 💖

okay bestie, pull up a chair 🫶 — this page is all about CosTransactions_Coordinator, an Erlang module from the cosTransactions family that literally implements the OMG CosTransactions::Coordinator interface. She's the coordinator. She coordinates. It's giving main character energy and it's fully deserved. 👑

---

🌸 DESCRIPTION 🌸

so if you wanna get access to the record definitions for the structures, you do this, no cap:

-include_lib("cosTransactions/include/CosTransactions.hrl").

that's it, that's the whole vibe check. include it and you're in. ✨

---

🎀 EXPORTS 🎀

create_subtransaction(Coordinator) -> Control

Types:

• Coordinator = #objref
• Control = #objref

okay so a brand new subtransaction gets created, and its parent is whatever Coordinator you handed over. it's giving "new baby transaction, who dis". 🍼

Raises exception:

• 'SubtransactionsUnavailable' — if nested transactions are not supported (she said no nesting today, sorry).
• 'Inactive' — if the target transaction has already been prepared.

---

get_transaction_name(Coordinator) -> Name

Types:

• Coordinator = #objref
• Name = string() of type "oe_name@machine_type_timestamp"

returns a printable string that describes the transaction. the whole point of it is to support debugging, so it's basically the transaction's little name tag for when you're out here trying to figure out what went wrong. 🏷️

---

get_parent_status(Coordinator) -> Status

Types:

• Coordinator = #objref
• Status = atom()

returns the status of the parent transaction associated with the target object. and heads up bestie: if the target object is a top-level transaction, this operation is literally equivalent to get_status/1. same thing, no difference, periodt.

Possible Status replies:

• 'StatusCommitted'
• 'StatusCommitting'
• 'StatusMarkedRollback'
• 'StatusRollingBack'
• 'StatusRolledBack'
• 'StatusActive'
• 'StatusPrepared'
• 'StatusUnknown'
• 'StatusNoTransaction'
• 'StatusPreparing'

---

get_status(Coordinator) -> Status

Types:

• Coordinator = #objref
• Status = atom()

returns the status of the transaction associated with the target object. simple as that, queen. 💅

---

get_top_level_status(Coordinator) -> Status

Types:

• Coordinator = #objref
• Status = atom()

returns the status of the top-level transaction associated with the target object. going all the way up the chain, iykyk.

---

hash_top_level_tran(Coordinator) -> Return

Types:

• Coordinator = #objref
• Return = integer()

returns a hash code for the top-level transaction associated with the target object. and ngl, if the target object is a top-level transaction, this equals the hash_transaction/1 operation. same number, different door. 🔢

---

hash_transaction(Coordinator) -> Return

Types:

• Coordinator = #objref
• Return = integer()

returns a hash code for the transaction associated with the target object.

---

is_descendant_transaction(Coordinator, OtherCoordinator) -> Return

Types:

• Coordinator = #objref
• OtherCoordinator = #objref
• Return = Boolean

returns true if the transaction associated with the target object is a descendant of the transaction associated with the parameter object. family tree check. 🌳

---

is_same_transaction(Coordinator, OtherCoordinator) -> Return

Types:

• Coordinator = #objref
• OtherCoordinator = #objref
• Return = Boolean

returns true if the transaction associated with the target object is related to the transaction associated with the parameter object. related, not identical — read the words bestie, they matter. 👀

---

is_top_level_transaction(Coordinator) -> Return

Types:

• Coordinator = #objref
• Return = Boolean

returns true if the transaction associated with the target object is a top-level transaction. is she the head of the table? this tells you. 👑

---

register_resource(Coordinator, Resource) -> RecoveryCoordinator

Types:

• Coordinator = #objref
• Resource = #objref
• RecoveryCoordinator = #objref

this operation registers the parameter Resource object as a participant in the transaction associated with the target object. and the RecoveryCoordinator she hands back can be used by this Resource during recovery. so like, keep it, you'll want it later. 🫶

Note: the Resources will be called in FIFO-order when preparing or committing. so be sure to register the Resources in the correct order. this is not a drill, order matters fr fr. 💀

Raises exception:

• 'Inactive' — if the target transaction has already been prepared.

---

register_subtran_aware(Coordinator, SubtransactionAwareResource) -> Return

Types:

• Coordinator = #objref
• Return = ok

this operation registers the parameter SubtransactionAwareResource object such that it will be notified when the transaction associated with the target object has committed or rolled back. she'll text you when it's done. 📲

Note: the Resources will be called in FIFO-order. so be sure to register the Resources in the correct order. same rule as before, don't get it twisted. 🦋

---

rollback_only(Coordinator) -> Return

Types:

• Coordinator = #objref
• Return = ok

the transaction associated with the target object gets modified so the only possible outcome is to rollback the transaction. that's it. no committing. the door is closed, the vibe is over, we're rolling back. 🚪💥

---

and that's the whole page bestie, you ate it. this gorgeous little number is brought to you by Ericsson AB, from cosTransactions version 5.2.2, page CosTransac...Coordinator(3). slay, go forth, and may your transactions never be 'Inactive' when you least expect it. 💅✨🎀