Transaction Demarcation:
The heart of any business transactional applications is transactional manamgement. No need to specify if it a financial applications like bank applications, how important is the transaction management. There are certain ground rules laid out by our industry expert on how we must handle this. But there is always a gap, unless you put our mind there.This is a primary concern for any database application. While I was looking at the health of an application based on my earmarked points such is one Transactions managment, I got into the following. These appears as fundamental mistakes. Let see what are the mistakes
MethodA(par1, parm2....){
xxxxx.;
yyyyf...;
x.MethodB(p1, p2, ....);
delete(Object);
getTm().commit();
}
MethodB(p1,p2, ...){
xxxxx;
yyyyy;
y.MethodC(p1);
delete(object);
getTm().commit();
}
MethodC(p1){
xxxxx;
yyyyy;
delete(object);
getTm().commit();
}
MethodA was called from coarse grained method service. MethodB was called from fine grained service and as well MethodC.
What are the problems you could see here?
let's take a look at points take at architecture and design level
Architecture:
1. Layer of maintaining transactions
2. Transactions management patterns
3. programming or declarative transaction management
Design:
1. Confirming ACID properties
2. Single Unit of work
3. Considering Exceptions
4. Transaction demarcation
