This section summarizes some high-level guidelines for using transactions. These are not hard and fast rules, but guidelines that should be evaluated in a specific application context.
Avoid (or at least minimize) the use of Java monitors in transactions.
Avoid deadlocks. When locking multiple objects always lock them in the same order. Concurrently locking objects in different orders can result in deadlocks. ActiveSpaces® Transactions detects and handles these deadlocks transparently, but it is less expensive to avoid them.
Avoid promotion deadlocks. When an object is going to be modified (written) within a transaction, take the write lock first, instead of the read lock. This avoids the possibility of a promotion deadlock between multiple transactions. Again ActiveSpaces® Transactions detects and handles these deadlocks transparently, but it is less expensive to avoid them.
Avoid resource contention. Avoid adding single points of contention to your application. If your application executes multiple threads concurrently insure that each thread uses separate resources.
Attempt to minimize the duration of transaction locks to avoid lock contention. For example, blocking with transaction locks held waiting for data from an external source, or sleeping with transaction locks held, is generally a bad thing.
Attempt to do all I/O outside of a transaction when the external system is non-transactional. If this cannot be avoided, use asynchronous I/O if available, to avoid blocking in a synchronous I/O operation with an active transaction.