This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
This is a question from GAMMA mock exam. What is the default transaction isolation level ? A. READ_UNCOMMITTED B. READ_COMMITTED C. REPEATABLE_READ D. SERIALIZABLE Doesn't the default isolation level depend on the underlying database's default ?? Any thoughts ??
I agree with you that the default isolation will depend on the underlying database. I looked at the WebLogic 6.1 documentation and did not see a default value for <transaction-isolation>. I'll see if I can chase down an answer for you later.
Originally posted by prasun dash: This is a question from GAMMA mock exam. What is the default transaction isolation level ? A. READ_UNCOMMITTED B. READ_COMMITTED C. REPEATABLE_READ D. SERIALIZABLE Doesn't the default isolation level depend on the underlying database's default ?? Any thoughts ??
This is from the ejb spec regarding isolation levels.
17.3.2 Isolation levels Transactions not only make completion of a unit of work atomic, but they also isolate the units of work from each other, provided that the system allows concurrent execution of multiple units of work. Support for Transactions Enterprise JavaBeans 2.0, Final Release Bean Provider’s responsibilities Sun Microsystems, Inc. The isolation level describes the degree to which the access to a resource manager by a transaction is isolated from the access to the resource manager by other concurrently executing transactions. The following are guidelines for managing isolation levels in enterprise beans. • The API for managing an isolation level is resource-manager specific. (Therefore, the EJB architecture does not define an API for managing isolation level.) • If an enterprise bean uses multiple resource managers, the Bean Provider may specify the same or different isolation level for each resource manager. This means, for example, that if an enterprise bean accesses multiple resource managers in a transaction, access to each resource manager may be associated with a different isolation level. • The Bean Provider must take care when setting an isolation level. Most resource managers require that all accesses to the resource manager within a transaction are done with the same isolation level. An attempt to change the isolation level in the middle of a transaction may cause undesirable behavior, such as an implicit sync point (a commit of the changes done so far). • For session beans and message-driven beans with bean-managed transaction demarcation, the Bean Provider can specify the desirable isolation level programmatically in the enterprise bean’s methods, using the resource-manager specific API. For example, the Bean Provider can use the java.sql.Connection.setTransactionIsolation(...) method to set the appropriate isolation level for database access. • For entity beans with container-managed persistence, transaction isolation is managed by the data access classes that are generated by the container provider’s tools. The tools must ensure that the management of the isolation levels performed by the data access classes will not result in conflicting isolation level requests for a resource manager within a transaction. • Additional care must be taken if multiple enterprise beans access the same resource manager in the same transaction. Conflicts in the requested isolation levels must be avoided. So it looks like though we can set the Isolation levels we need the database to support it. [ May 13, 2002: Message edited by: Rahul Mahindrakar ]
Hi, You cannot modify the isolation level of entity beans with container-managed persistence. These beans use the default isolation level of the DBMS, which is usually READ_COMMITTED, but if you�re using BMP or going to the DB using session beans you can allways control the isolation level using, for example: Connection con; con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
I disagree with u that one cannot set the isolation level for entity beans with container managed persistence. Weblogic server 6.1 supports 4 isolation levels Serializable | ReadCommitted | ReadUncommitted | RepeatableRead. But before specifying a isolation level one needs to read the database documentation to see that isolation level are supported. For more information read the weblogic doc on EJB.The isolation-level element in weblogic-ejb-jar.xml is used to specify the isolation level.
Originally posted by Marcos Maia: Hi, You cannot modify the isolation level of entity beans with container-managed persistence. These beans use the default isolation level of the DBMS, which is usually READ_COMMITTED, but if you�re using BMP or going to the DB using session beans you can allways control the isolation level using, for example: Connection con; con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
The EJB specification does not set forth a standard way to assign isolation levels when we use container-managed transactions. To support contro over isolation, a J2EE implementation has to allow us to specify the levels at deployment. If your application server cannot do this, the default isolatin for each resource manager is used. (i.e. READ_COMMITTED will be applied to all database access.)
Joined: Mar 11, 2001
To summarize this thread... WebLogic allows the the database isolation level to be set to one of four values: (1)Serializable (2)ReadCommitted (3)ReadUncommitted (4)RepeatableRead This lets the a developer set the database isolation level to whatever the target database supports instead of using the default, READ_COMMITTED. Any additional comments? [ May 15, 2002: Message edited by: Michael Pearson ]