Somehow in last 8 months I have been working on things which needed effective Thread-Safe libraries. So in due process of making them I had encountered different approaches in dealing with them in terms of the mutability of the data. This blog is related to the best approach I have realized:
Well in a way almost all major frameworks follow it. The database model’s are built around it. But from a developer point of view I will tell you the reason why I prefer it the most:
- When a transaction is committed, the changes or the inputs in the transaction is the only stuff which needs to be done at that particular moment. Thus in a way there is no need to deal with the situation where you expect many changes from different threads all the time. The libraries are Thread-Safe through Thread Confinement. The Transactions can be executed wither sequentially or in parallel depending upon the scope of the transaction but ultimately satisfying Thread Confinement. Thus solving the whole problem of building design models rather than updating data/states on the go.
- One of my favorite quotes:
Nature Loves Simplicity
The whole concept of a transaction is pretty simple for a developer who is working on an API built around it. it is simple to understand and execute.
- Response: For example Neo4J: I just love the whole format of how data/traversals in nodes/relationship’s are embedded inside a Transaction. As an neo4j programmer it is pretty simple to me; That if the transaction is succesful then the changes shall be made or else not. In other cases where every change is to be made, making a response system would make it complicated in return.
This was one of the problems I faced while working on ISO standard 5 for GNU prolog for Java. In a way I should have followed the same transaction model given almost all follow it. Clojure also does it the same way (but only provides ACI instead of ACID)