What is Transaction?
A transaction is a unit of work that involves one or
more resources and is either completed in its entirety or is not done at all.
Participating resources are locked for the duration of the transaction.
Depending on the readiness of all the participating resources, the changes made
to the resources are either committed or rolled back, and the lock is released.
To further understand
the transaction let’s take a look at real life example of Net Banking, suppose
you want to transfer some money from your own account to your
mother’s account this process of transferring money from one
account to another
can be viewed as made up of following main tasks
1) Debiting
specified amount from your bank account ledger
2) Crediting
same amount into your mother’s bank
account ledger
Transferring process will be complete only if both task
completed successfully not otherwise. This means transfer of money from one
account to another fulfill criteria of being a transaction.
Most of the
ecommerce sites rely on other third-party services for as a part of there
business process e.g. consider an example of air ticket booking sites like
www.yatra.com or www.makemytrip.com
usually
to get best air ticket deal to there customer these site need to interact with
different airlines having there own ticket booking facility through there own
systems. Ticket for given seat in given airline on given date time should be
booked at most once. Money transaction from customer to
air ticket booking site should be completed successfully
that also depend on third party payment gateways like say PayPal.
In such scenario
we need to ensure that process completed in its entirety or is not done at all.
Locking of resources of one party from other will concede control of once
resources to other, making participating parting susceptible to Denial of
Services attack situation demand transaction that may not necessary fit into
ACID Property that we usually associate with Database transactions.
Let’s imagine a service composition that invokes a decision service to validate request data, proceeds to update a customer entity via an entity service, and then sends a message on a queue for an external process to consume. Consider the three steps as part of a single unit of work – a service transaction that execute in sequence.
If runtime exceptions associated with the composition are unhandled there is an increased likelihood of compromising data and business integrity. The compensating service transaction pattern introduces additional compensation steps in order to handle runtime exceptions without locking system resources. These additional steps can be included as part of the composition logic or made available as separate undo service capabilities. Continuing the earlier example, a call to undo the customer update (essentially resetting the data back to the earlier state) can be made to place the underlying data in a valid state.
The compensation-based transactions have the following salient features:
- Ability to manage consistency of data across applications without locking resources
- Coordination of various transaction participants without giving complete authority to a central transaction manager
- Ability to work in scenarios where participants' availability and/or response is not guaranteed
It is necessary to ensure that the compensating steps
themselves execute successfully. Error alerts/notifications may need to be sent
in case compensations fail and manual interventions are needed.
The Compensating Service Transaction pattern provides several benefits:- Eliminates the need for executing distributed service invocations within a transactional context.
- Provides a mechanism for services/resources that don’t support atomic transactions to participate in service compositions.
- Reduces load on underlying systems and databases by only invoking compensation routines when failure occurs. Instead of locking resources in case failures happen, the idea is to handle runtime exceptions when they actually occur.
- Allows reuse of compensation steps across service compositions. E.g. two business services that update a data entity can reuse the undo Update capability.
Reference:
No comments:
Post a Comment