The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Best Practice: Reducing the transaction isolation level in EJBs

Harvey Gunther, Senior Performance Analyst, IBM

Harvey W. Gunther is a Senior Perfomance Analyst for the WebSphere product development team in Raleigh, NC.

Summary: Reduce the EJB transaction isolation level where possible to reduce the overhead of database concurrency. In many cases, better performance may be realized by changing the defaults.

Tag this!

Date: 16 Oct 2001
Level: Intermediate

Activity: 5565 views
Comments:

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

Recommendation

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.

Alternative

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.

Resources

WebSphere Application Server Development Best Practices for Performance and Scalability

About the author

Harvey W. Gunther is a Senior Perfomance Analyst for the WebSphere product development team in Raleigh, NC.

Close [x]

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.

Close [x]

Report abuse help

Report abuse

Report abuse submission failed. Please try again later.

Close [x]

developerWorks: Sign in

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

Close [x]

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

All information submitted is secure.

Rate this article

Comments

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=WebSphere

ArticleID=14020

ArticleTitle=Best Practice: Reducing the transaction isolation level in EJBs

publish-date=10162001

author1-email=

author1-email-cc=