Transactions (Serialization Process)
Transactions are also known as input/output serialization or serialization process where each input/output "action" are performed with complying to ACID principles:
- Atomic - all or nothing
- Consistency - application-dependent as before
- Isolation - each transaction runs alone
- Durability - not able to undo. Staying persistently.
There are various methods to achieve transaction processes.
2-Phases Locking (2PL)
This method uses a locking mechanism (like synchronized mutex in programming language) to process data transaction. The idea is that before processing data, each submitter/committer must acquire locking from the database server and reject the similar requests later on. Hence, only 1 submitter can process the data at a time.
The 1st phase is acquire the locking and then process the data after a successful acquisition.
The 2nd phase is after processing the transaction, the lock is released.
The problem with this is that:
- When using synchronized locking, you introduces its accompanying dead-lock and race-condition problems potentials.
- All participants must agree whether the transaction should be committed or dropped.
2-Phases Commit (2PC)
This method uses a coordinator server to perform commit coordination.
The first phase is "voting" phase / prepare phase. The coordinator server tracks and send "can commit" signal to all participants. Each participants replies "yes/no" back to the server for majority answer. If the answer is "yes", the object is locked for transaction. If any participant replies "no", the server send the "abort transaction" signal to all participants.
The second phase is the commit or abort action depending on the final vote.
The problem with this is that:
- A server welcomes all the server operations, network, overloading, etc issues.
- Many round-trip messages
- Temporary failure can arbitrary delay a commit.
Transaction ID
Another method is to apply a randomized transaction ID to track the last successful transaction. Hence, the client must request an empty transaction request "skeleton" containing that last transaction ID. Upon filling up, the client then submit it to the server.
The server follows first in first out policy. The first successful submission will be transacted and the last transaction ID is updated.
The way the server does it is that:
- It first reads the submission transaction ID and compare with the last existing transaction.
- If they are the same, it means the history is on-track and the server accepts the process. Otherwise, the server will reject the request stating the it is outdated.
The problem with this is that:
- It reduces the impacts of duplicated request but it does not solve the simultaneous requests.
- A policy is needed for simultaneous processing.
Caveat
The problem with is that you can't implement all of them. The maximum methods you can do is 2 out of the 3. Normally, in such scenario, the business policy kicks in and compliment the weakness.
Example, for hotel booking, if simultaneous entry occurred, it is known as double booking in business term. The system is still tracking the double booking and alerted the business acumen about this. Then, depending on hotel policy, the business acumen contacts either one of the client to perform booking alteration.
That's all about transaction process.