Ah... this is a tough question because at Sun, the position is that isolation levels are *not* supposed to be something the bean developer should be involved in, and that this is purely a DBA issue. You *can* still set the isolation level at the "local resource level" (note to everyone here, nothing about isolation levels is on the exam , but it's not recommended. So, I'm going to wimp out and say that "the best practice for isolation levels is to leave it up to your database administrator". And it's a best practice for the bean developer personally, because I know I've worked with some DBA's who would pretty much threaten to kill you if you even *thought* about messing with isolation levels on the database. The attitude is, "Your job is to just do your updates, inserts, etc. and let US (meaning the DBAs) worry about the isolation levels." But having said that... it does depend on two things: 1) the nature of your application (for example, is it truly critical that you never get an uncommitted read?) 2) the type of database that you're using, or more specifically--the type of locking mechanism that your database uses. If you want maximum safety, you can just crank the dial on the isolation level all the way up to the "serializable" level. But that brings your concurrency down. So the general rule is that for performance you should always choose the LEAST restrictive isolation level that you can live with for your application, and consider the type of locking your particular database uses. Still, though, you should try to avoid doing any of this from within your bean code! That will hurt the maintenance and reuse of your bean (if you set isolation levels on the resource in code, you would have to recode/recompile/retest your bean in order to make changes), and again, it's really a decision that should be pushed down to the database. Most databases use one of the two middle levels of isolation as a default, and you can probably accept that unless you have some highly critical data where you need to strengthen the isolation (brining your concurrency down) or, the opposite, you have data where it really doesn't matter -- you just need a rough snapshot of what the database looks like at the time you do the read and it's not important if you get dirty reads, etc. Hope that helps a little... sorry my answer is so wimpy , but I'm not a database admin and this isn't part of the EJB specification. (Although there used to be a way to set isolation levels on *CMT*, but that was in the first version of EJB and it caused all sorts of horrible problems so it was eliminated from the spec.) My advice: leave it up to the database admin, but if you really need to do this yourself (like maybe you are supposed to wear BOTH the bean developer and database admin hat), then you'll have to consider the performance tradeoffs based on your specific business logic based on how your particular database does locking. cheers, Kathy
Thanks, Kathy. So, how is it handled in DD if we have to (as suggested on page 56 of Core J2EE Patterns by Deepak Alur et al, for example)? I am asking about the issue, because many industrial applications are still using session beans with BMT to handle the transaction isolation levels, even though they are using EJB 2.0. Hope you can help. Thanks!