Database Reference
In-Depth Information
Some saga features
As we have mentioned, sagas are design patterns. This means that they are reusable pat-
terns used in designing software for the purpose of saving different states in messages, as
they are processed through an end-to-end workflow. They have many features and charac-
teristics:
• Sagas are started by a message, maybe more than one. A saga is started by a mes-
sage in the interface, for example,
"IAmStartedByMessage<Message1>"
.
• Sagas contain
long-lived transactions
(
LLTs
) that contain database information
for the messages for relatively long periods of time. LLT is used when conditions
such as short-lived transactions are not adequate. A short-lived transaction is when
a call to a database, or MSQM, performs a straightforward rollback or commit. For
queues, NServiceBus performs
second-level retries
(
SLRs
) to try to commit a
number of times before performing a rollback. In LLT, there can be multiple condi-
tions and actions that need to take place for a message to be fully completed, or op-
erations performed to start the message right from the beginning. LLT is used for
messages where a simple short-term transaction may not suffice. In an SOA, there
are multiple endpoints and services. Most messages will start with a starting type
and will continue to pass through different services in an SOA, all the while com-
pleting operations and updating information. They will start as one type and pass
through a service when they change to a different type of message. During these
transformations of the message, a saga can globally keep track of the message's
state through this workflow of services. It can respond back to the different origin-
ating services indicating that everything was processed successfully, or respond
that there were errors and that there is a need to rollback the message to each cli-
ent.
• Sagas contain timeout. There is a condition where a message needs to have a timer
to interrupt its actions regardless of what it is doing. Going back to the pizza-order-
ing example, we may want to check with the customer whether the order takes
longer than 20 minutes to see if they still wish to order the pizza. For this reason,
you may want to interrupt the order in progress, which is in the form of a message,
and time it out and check with the customer before proceeding.
• Sagas contain state-related information. Sagas save saga data to the database. Saga
data is initially started with a message, and it is also updated with messages that
are passed in with the same identification information. When a message passes
between different services in an end-to-end workflow, saving the state information
before the next service is wise if it needs to change back to its original state.
