Transaction, maintainability and performance

Transaction management strategies on high performance application. This is an interesting topic, I guess, since many of enterprise applications have such problem.

Most of the enterprise applications are having a problem of performance because they maintain ACID in every of their transaction. Thus, the transaction will be atomic. Imagine that we have a few transactions, 100 transactions maybe, that we need to maintain the atomic-ity of these transactions for only one action of user (clicking certain button). And definitely, the user of some applications are not only 1, so it will cost more slowness. The more users who access your application at the same time, the more slow of your application will be.

Sometime, we sacrifice performance for application's design. we usually choose to have a good design of the application rather than a high performance of application. For example, the use of ORM, let's say hibernate. Using this kind of ORM, definitely, will slow down your application. But, it will make your application more portable if you want to use another database and also, it will make the code of your application much more maintainable.

This kind of trade off cannot be avoided. It will always exist in every of software development. However, it needs to be assessed and evaluated so that those factors can benefit end user.

One thing that may come on your mind is the use of stored procedure to leverage the performance. Why does stored procedure can be used to leverage the performance instead of having plain sql? Because stored procedure is a precompiled sql statement and also less data being transferred between application and database server. Unfortunately, not many ORM fully support store procedure. The only ORM that I know which supports store procedure is Hibernate. For detail about store procedure can be seen on the link below:
http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html#sp_query