ACID stands for atomicity, consistency, isolation and durability. Any transactional system needs to provide these properties. In file based system, it was the problem of designer and implementor(coder) to arrange for these properties. Then with advent of RDBMS these responsibilities were taken up by RDBMS. Again, in early days of distributed computing, the responsbility (of two phase commit) fell on designers/coders. Then came XA open architecture and introduced transaction co-ordinator in every RDBMS. Life became easier after that (from ACID perspective).
ACID is critical for transactional systems. Services in SOA do not guarantee ACID properties. They require compensatory services to achieve ACID effect. Those of you, who have worked with 'file' based information systems and then moved onto work with RDBMS, will understand my concern about services not being ACID, more. Because in a OLTP world, a transaction followed with some delay by a compensatory transaction, is not exactly equivalent to a ACID transaction. This may not affect in most cases, but when it does, the effect can be pretty nasty. Especially when a service executes an automated protocol in one service call and then try to undo its effects using a compensatory service. This kind of thing happens in a straight thru processing scenario. This remains one of my major concerns.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Subscribe to:
Post Comments (Atom)
Thursday, December 14, 2006
Services are not ACID
ACID stands for atomicity, consistency, isolation and durability. Any transactional system needs to provide these properties. In file based system, it was the problem of designer and implementor(coder) to arrange for these properties. Then with advent of RDBMS these responsibilities were taken up by RDBMS. Again, in early days of distributed computing, the responsbility (of two phase commit) fell on designers/coders. Then came XA open architecture and introduced transaction co-ordinator in every RDBMS. Life became easier after that (from ACID perspective).
ACID is critical for transactional systems. Services in SOA do not guarantee ACID properties. They require compensatory services to achieve ACID effect. Those of you, who have worked with 'file' based information systems and then moved onto work with RDBMS, will understand my concern about services not being ACID, more. Because in a OLTP world, a transaction followed with some delay by a compensatory transaction, is not exactly equivalent to a ACID transaction. This may not affect in most cases, but when it does, the effect can be pretty nasty. Especially when a service executes an automated protocol in one service call and then try to undo its effects using a compensatory service. This kind of thing happens in a straight thru processing scenario. This remains one of my major concerns.
ACID is critical for transactional systems. Services in SOA do not guarantee ACID properties. They require compensatory services to achieve ACID effect. Those of you, who have worked with 'file' based information systems and then moved onto work with RDBMS, will understand my concern about services not being ACID, more. Because in a OLTP world, a transaction followed with some delay by a compensatory transaction, is not exactly equivalent to a ACID transaction. This may not affect in most cases, but when it does, the effect can be pretty nasty. Especially when a service executes an automated protocol in one service call and then try to undo its effects using a compensatory service. This kind of thing happens in a straight thru processing scenario. This remains one of my major concerns.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment