Atomic transaction in J2EE

As budding developers, most of us tend to debate on certain technologies out there and comment on which is better than which and why. dotNet developers will argue that J2EE is so hard to use while the latter will comment that dotNet does not scale and is not as reliable. Even within the J2EE environment, some developers does not see EJB as a useful feature of J2EE and comment that it is difficult to develop and the same results can be achieved merely by using JDBC. There are even others who said that using stored procedures will result in most efficient code. Efficient here means fastest to execute and return desired results. As I am also one of the budding developers, I also face this type of debates most of the time. I still does not know which one is most efficient and which one should I use in which type of situation. However, I does realize the fact that session beans and entity beans removed a lot of the headache of maintaining transactions in JDBC environment. Container managed transaction is a blessing for Java developers. Anyway, the point is, I actually like to find out WHAT IF the transaction that is guaranteed by the container fails. I mean, say the task A and task B must occur as one atomic transaction but actually only task A managed to run but the transaction is unable to roll it back or worst, does not even realized it. Who would be responsible for this behavior? Most of the time it would be developers fault for not understanding the J2EE spec correctly and made mistakes while developing, however one cannot simply rule out that the application server vendor is not at fault. What if this funny behavior is randomly appearing at production systems and the developers are sure that their application are coded correctly. Who are liable for financial lost that occurred because of application servers funny inconsistent behavior?