This best practice applies to the following product, version, and platforms:
- WebSphere Application Server - Base, versions 3.0.2.x, 3.5.x, 4.0, all platforms
By default, most developers deploy EJBs with the transaction isolation level set to TRANSACTION_SERIALIZABLE or TRANSACTION_REPEATABLE_READ . TRANSACTION_REPEATABLE_READ is the default in IBM VisualAge for Java, Enterprise Edition and other EJB deployment tools. TRANSACTION_SERIALIZABLE is the most restrictive and protected transaction isolation level incurring the most overhead.
Some workloads do not require the isolation level and protection afforded by TRANSACTION_SERIALIZABLE or TRANSACTION_REPEATABLE_READ . A given application might never update the underlying data or be run with other concurrent updaters. In that case, the application would not have to be concerned with dirty, non-repeatable, or phantom reads. TRANSACTION_READ_UNCOMMITTED would probably be sufficient.
Because the EJB's transaction isolation level is set in its deployment descriptor, the same EJB could be reused in different applications with different transaction isolation levels. Review your isolation level requirements and adjust them appropriately to increase performance. Figure 1 shows the performance impact of reducing transaction isolation levels.
Figure1. Performance Impact - Reducing Transaction Isolation Levels
For EJB applications, set your transaction isolation level based on your actual concurrency needs. If not required, do not use higher transaction isolation levels. Higher restrictive isolation levels increase the overhead.
You can use the defaults as noted above in the deployment descriptors of an EJB, but better performance may be achieved by modifying these values to the specific needs of your application.
Comments (Undergoing maintenance)





