Transactions
Transactions have many overheads. If you can avoid them, do so for performance reasons. Handle the nontransactional part of your application differently from the parts that require transactions. Where transactions are necessary, tune transactions using the following guidelines:
Try to use optimistic transactions (the Optimistic Locking design pattern) for transactional systems in which accesses predominate updates.
Minimize the time spent in any transaction, but don’t shorten transactions so much that you unnecessarily increase the total number of transactions. Combine transactions that occur within a few seconds of each other to minimize the overall time spent in transactions. This can require manually controlling the transaction—i.e., turning off auto-commit for JDBC transaction or using TX_REQUIRED for EJBs.
J2EE transactions are defined with several isolation modes. Choose the fastest transaction isolation level that avoids corrupting the data. Transaction levels in order of increasing cost are: TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, and TRANSACTION_SERIALIZABLE.
Don’t leave transactions open, relying on the user to close them. Inevitably, there will be times when the user does not close the transaction, and the very long transaction that results will significantly decrease the performance of the system.
Bulk or batch updates are usually more efficiently performed in larger transactions.
Optimize read-only transactions. ...