Default transaction isolation level

Hi,
What is the default transaction isolation level in weblogic?
Is it dependent on the database isolation level?
Pradeep bhat

In 6.1, the default transaction isolation level for CMP beans is the level specified
in the database.
In 5.1, the default is supposed to be serializable, though there is a bug in 5.1
that does not set the level at all. I have received a confirmation from Weblogic
that this is a bug.
Dan
"pradeep bhat" <[email protected]> wrote:
>
Hi,
What is the default transaction isolation level in weblogic?
Is it dependent on the database isolation level?
Pradeep bhat

Similar Messages

What is ths default transaction isolation level

Hi ,
          If transaction isolation , for a EJB is not specified what is the
          default transaction isolation level
          Thanks
          Jay


serializable
          Cameron Purdy
          Tangosol, Inc.
          http://www.tangosol.com
          +1.617.623.5782
          WebLogic Consulting Available
          "mrityunjay" <[email protected]> wrote in message
          news:3a86c781$[email protected]..
          > Hi ,
          > If transaction isolation , for a EJB is not specified what is the
          > default transaction isolation level
          > Thanks
          > Jay
          >
          >

Default transaction isolation level in CR

i am a newbie to CR.what is default transaction isolation for Crystal Reports XI. Where can i see it?

Hello,
The default is committed only. There was an option in ODBC only that CR could set uncommitted reads but R&D determined using Dirty Reads would skew the numbers so it was safer to turn it off.
If you want to use or not use it then do it server side, becomes your configuration settings.
Thank you
Don

Transaction Isolation Level to Read UnCommited in Non OLTP Database

HI,
We are having a database which for NOT OLTP process. That is OLAP DB. Operation on that DB is only Select and (Incremental Insert - FOR DWH ) not Update/Delete and we are performing ROLAP operations in that DB.
By Default SQL Server DB isolation Level is READ COMMITTED.AS Our DB IS OLAP SQL Server DB we need to change the isolation level toRead Uncommited. We google it down but We can achive in
Transaction level only by SET isoaltion Level TO Read UNCOMMITED
or ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Is there any other way if we can Change the Database isolation level to READ uncommitedfor Entire Database?, insteads of achiving in Transaction Level or With out enabling SET ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Please use Marked as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
Please use Marked as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

Hi,
My first question would be why do you want to change Isolation level to read uncommitted, are you aware about the repercussions you will get dirty data, a wrong data.
Isolation level is basically associated with the connection so is define in connection.
>> Transaction level only by SET isoaltion Level TO Read UNCOMMITED or ALLOW_SNAPSHOT_ISOLATION ON or READ_COMMITTED_SNAPSHOT
Be cautious Read UNCOMMITED and Snapshot isolation level are not same.The former is pessimistic Isolation level and later is Optimistic.Snapshot isolation levels are totally different from read uncommitted as snapshot Isolation level
uses row versioning.I guess you wont require snapshot isolation level in O:AP DB.
Please read below blog about setting Isolation level Server wide
http://blogs.msdn.com/b/ialonso/archive/2012/11/26/how-to-set-the-default-transaction-isolation-level-server-wide.aspx
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers
My TechNet Wiki Articles

Locking issues with transaction-isolation levels

          I believe that my program is suffering from some sort of deadlock, and I was hoping
          for some feedback.
          I am helping to develop a trading system
          using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
          called LiveOrder that exposes several finder methods, most of which return java.util.Collections
          of LiveOrder EJBs.
          In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
          finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
          isn't really supported by Oracle), in an effort to eliminate phantom reads, which
          occur frequently if I do not use this isolation level. These finders all use transaction
          attribute 'Required'.
          It is my understanding that any transaction that calls any of these finders either
          will lock the database if no other transaction already owns the lock, or will
          wait until the lock is released if another transaction owns that lock. It also
          is my understanding that a transaction that owns a lock will always release any
          locks acquired upon expiration of that transaction (whether that be via commit
          or via rollback).
          However, this doesn't always appear the case: I have noticed occassionally that
          several clients "hang," as they wait for the lock that, for some reason, is not
          being released by its transaction. There do not appear to be any exceptions thrown
          by the system prior to the system hanging, and the Weblogic administration tool
          states that all transactions have been committed.
          If it helps, I have included the general algorithm for the main (i.e., most expensive)
          transaction:
          1. a client calls a stateless session EJB's processOrder method (which should
          implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
          2. the transaction invokes the LiveOrder finder method (this should lock the DB,
          so subsequent callers should block until the lock is released).
          3. the transaction invokes another LiveOrder finder method, returning a separate
          set of data.
          4. the transaction invokes a finder method from a separate entity EJB (called
          Security), which maps to a "read-only" table in the DB (default transaction-isolation
          level, Required attribute).
          5. the transaction invokes a finder method from yet another separate entity EJB
          (called SecurityMarketValues), which maps to some other table (not read-only)
          in the DB (again, default transaction-isolation level, Required attribute).
          6. the transaction writes to the SecurityMarketValues entity EJB.
          7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
          8. the transaction ends by exiting method processOrder (thus releasing the locks
          on the LiveOrder table in the DB).
          In the system, there also exist other transactions that occassionally call the
          LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
          order table (i.e., these transactions do not make calls to other DB tables, and
          close transactions almost immediately after starting them)
          Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
          ideas? I'm running out...


Jon,
          If there was an Oracle deadlock the DB would resolve it momentarily and
          will ultimately choose one transaction and throw an exception so it's
          not a DB deadlock.
          Take a thread dump at the very moment your system seems to be hanging
          and look at what the threads are doing.
          From your description it's not very unlikely that those threads of
          yours that take snapshots of the data will not disrupt the transactions
          so you may be surprised by the thread dumps that this is actually what
          happens -- those snapshot thread wait for some lock while holding locks
          needed by you other threads and it just slows down the system.
          Regards,
          Dejan
          Jon Gadzik wrote:
          >I believe that my program is suffering from some sort of deadlock, and I was hoping
          >for some feedback.
          >
          >I am helping to develop a trading system
          >using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
          >called LiveOrder that exposes several finder methods, most of which return java.util.Collections
          >of LiveOrder EJBs.
          >
          >In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
          >finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
          >isn't really supported by Oracle), in an effort to eliminate phantom reads, which
          >occur frequently if I do not use this isolation level. These finders all use transaction
          >attribute 'Required'.
          >
          >It is my understanding that any transaction that calls any of these finders either
          >will lock the database if no other transaction already owns the lock, or will
          >wait until the lock is released if another transaction owns that lock. It also
          >is my understanding that a transaction that owns a lock will always release any
          >locks acquired upon expiration of that transaction (whether that be via commit
          >or via rollback).
          >
          >However, this doesn't always appear the case: I have noticed occassionally that
          >several clients "hang," as they wait for the lock that, for some reason, is not
          >being released by its transaction. There do not appear to be any exceptions thrown
          >by the system prior to the system hanging, and the Weblogic administration tool
          >states that all transactions have been committed.
          >
          >If it helps, I have included the general algorithm for the main (i.e., most expensive)
          >transaction:
          >
          >1. a client calls a stateless session EJB's processOrder method (which should
          >implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
          >
          >2. the transaction invokes the LiveOrder finder method (this should lock the DB,
          >so subsequent callers should block until the lock is released).
          >
          >3. the transaction invokes another LiveOrder finder method, returning a separate
          >set of data.
          >
          >4. the transaction invokes a finder method from a separate entity EJB (called
          >Security), which maps to a "read-only" table in the DB (default transaction-isolation
          >level, Required attribute).
          >
          >5. the transaction invokes a finder method from yet another separate entity EJB
          >(called SecurityMarketValues), which maps to some other table (not read-only)
          >in the DB (again, default transaction-isolation level, Required attribute).
          >
          >6. the transaction writes to the SecurityMarketValues entity EJB.
          >
          >7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
          >
          >8. the transaction ends by exiting method processOrder (thus releasing the locks
          >on the LiveOrder table in the DB).
          >
          >
          >In the system, there also exist other transactions that occassionally call the
          >LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
          >order table (i.e., these transactions do not make calls to other DB tables, and
          >close transactions almost immediately after starting them)
          >
          >Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
          >ideas? I'm running out...
          >
          >
          >
          >

Setting transaction isolation level for jDriver Oracle/XA

edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a
transaction and that 'Transactions use the transaction isolation level set on
the connection
or the default transaction isolation level for the database'. Does this mean that
you shouldn't try to set it programatically (fair enough) or that you can't set
it in the weblogic deployment descriptor either? Also anybody got any idea what
the default is likely to be if you are using
an Oracle 9iR2 database?

Ian,
The default for Oracle (any version) is ReadCommitted. The only other
isolation level Oracle supports is Serializable but it's implemented in
such a way that you will be allowed to continue until commit time and
only then you might get an exception stating the the access for that
transaction could not be serialized.
I don't know for the jDriver but if you use the Oracle Thin XA driver
even if you set the isolation level in your descriptor you will get an
exception from Weblogic. It is a Weblogic bug and you can contact
[email protected] to get a patch.
Regards,
Dejan
IJ wrote:
edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
if using jDriver for Oracle/XA you can not set the transaction isolation level
for a
transaction and that 'Transactions use the transaction isolation level set on
the connection
or the default transaction isolation level for the database'. Does this mean that
you shouldn't try to set it programatically (fair enough) or that you can't set
it in the weblogic deployment descriptor either? Also anybody got any idea what
the default is likely to be if you are using
an Oracle 9iR2 database?

Bug in Oracle's handling of transaction isolation levels?

Hello,
I think there is a bug in Oracle 9i database related to serializable transaction isolation level.
Here is the information about the server:
Operating System:     Microsoft Windows 2000 Server Version 5.0.2195 Service Pack 2 Build 2195
System type:          Single CPU x86 Family 6 Model 8 Stepping 10 GenuineIntel ~866 MHz
BIOS-Version:          Award Medallion BIOS v6.0
Locale:               German
Here is my information about the client computer:
Operaing system:     Microsoft Windows XP
System type:          IBM ThinkPad
Language for DB access: Java
Database information:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
The database has been set up using the default settings and nothing has been changed.
To reproduce the bug, follow these steps:
1. Create a user in 9i database called 'kaon' with password 'kaon'
2. Using SQL Worksheet create the following table:
CREATE TABLE OIModel (
modelID int NOT NULL,
logicalURI varchar (255) NOT NULL,
CONSTRAINT pk_OIModel PRIMARY KEY (modelID),
CONSTRAINT logicalURI_OIModel UNIQUE (logicalURI)
3. Run the following program:
package test;
import java.sql.*;
public class Test {
public static void main(String[] args) throws Exception {
java.util.Locale.setDefault(java.util.Locale.US);
Class.forName("oracle.jdbc.OracleDriver");
Connection connection=DriverManager.getConnection("jdbc:oracle:thin:@schlange:1521:ORCL","kaon","kaon");
DatabaseMetaData dmd=connection.getMetaData();
System.out.println("Product version:");
System.out.println(dmd.getDatabaseProductVersion());
System.out.println();
connection.setAutoCommit(false);
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
int batches=0;
int counter=2000;
for (int outer=0;outer<50;outer++) {
for (int i=0;i<200;i++) {
executeUpdate(connection,"INSERT INTO OIModel (modelID,logicalURI) VALUES ("+counter+",'start"+counter+"')");
executeUpdate(connection,"UPDATE OIModel SET logicalURI='next"+counter+"' WHERE modelID="+counter);
counter++;
connection.commit();
System.out.println("Batch "+batches+" done");
batches++;
protected static void executeUpdate(Connection conn,String sql) throws Exception {
Statement s=conn.createStatement();
try {
int result=s.executeUpdate(sql);
if (result!=1)
throw new Exception("Should update one row, but updated "+result+" rows, query is "+sql);
finally {
s.close();
The program prints the following output:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.lang.Exception: Should update one row, but updated 0 rows, query is UPDATE OIModel SET logicalURI='next2571' WHERE modelID=2571
     at test.Test.executeUpdate(Test.java:35)
     at test.Test.main(Test.java:22)
That is, after several iterations, the executeUpdate() method returns 0, rather than 1. This is clearly an error.
4. Leave the database as is. Replace the line
int counter=2000;
with line
int counter=4000;
and restart the program. The following output is generated:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
     at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
     at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
     at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
     at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
     at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)
     at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)
     at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
     at test.Test.executeUpdate(Test.java:33)
     at test.Test.main(Test.java:22)
This is clearly an error - only one transaction is being active at the time, so there is no need for serialization of transactions.
5. You can restart the program as many times you wish (by chaging the initial counter value first). The same error (can't serialize access for this transaction) will be generated.
6. The error doesn't occur if the transaction isolation level isn't changed.
7. The error doesn't occur if the UPDATE statement is commented out.
Sincerely yours
     Boris Motik

I have a similar problem
I'm using Oracle and serializable isolation level.
Transaction inserts 4000 objects and then updates about 1000 of these objects.
Transactions sees inserted objects but cant update them (row not found or can't serialize access for this transaction are thrown).
On 3 tries for this transaction 1 succeds and 2 fails with one of above errors.
No other transactions run concurently.
In read commited isolation error doesn't arise.
I'm using plain JDBC.
Similar or even much bigger serializable transaction works perfectly on the same database as plsql procedure.
I've tried oci and thin (Oracle) drivers and oranxo demo (i-net) driver.
And this problems arises on all of this drivers.
This problem confused me so much :(.
Maby one of Oracle users, developers nows cause of this strange behaviour.
Thanx for all answers.

Regarding Transaction Isolation Level

We talk about query and update constent problem again. even I don't take it as problem.
I can see this in SAP notes or SAP help:
JDBC Sender Adapter...
· The UPDATE statement must alter exactly those data records that have been selected by the SELECT statement. You can ensure this is the case by using an identical WHERE clause. (See Processing Parameters, SQL Statement for Query, and SQL Statement for Update below).
· Processing can only be performed correctly when the Transaction Isolation Level is set to repeatable_read or serializable.
If I set transaction isolation level as default, then how can I make sure ' default' is repeatable_read or serializable?
Our DB is Informix.

Hey
Please go through the below blog and see if it helps
/people/yining.mao/blog/2006/09/13/tips-and-tutorial-for-sender-jdbc-adapter
Thanks
Aamir

Setting transaction isolation level rises ORA-02089 error

Hello
We have configured a distributed transaction in our application server and
we are using openjpa 1.2.1 and Glassfish application server and Oracle 11g as DB server. Although the default behavior of transaction locking must be optimistic,
it seems that pessimistic locking has been happened.
It is found that Row Lock contention happens in a specific table.
This is the exception :
java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock
Already all the following properties have been set for openjpa.
1. <persistence-unit name="JPXA" transation-type="JTA">
2. <property name="openjpa.TransactionMode" value="managed"/>
You can try a plug-in string to lookup the TM in JNDI (the value is the JNDI name of GlassFish TM as per Google search)
3. <property name="openjpa.ManagedRuntime"
value="jndi(TransactionManagerName=java:appserver/TransactionManager)"/>
Following searching about this locking problem, we found that we should add two more properties for openjpa as listed below.
<property name="openjpa.LockManager" value="version" />
<property name="openjpa.jdbc.TransactionIsolation" value="read-committed" />
but this time by setting the transaction isolation level, we have got another error: org.apache.openjpa.persistence.PersistenceException: ORA-02089: COMMIT is not allowed in a subordinate session.
Thanks for any help.
Regards,
Sargol

Hello
We have configured a distributed transaction in our application server and
we are using openjpa 1.2.1 and Glassfish application server and Oracle 11g as DB server. Although the default behavior of transaction locking must be optimistic,
it seems that pessimistic locking has been happened.
It is found that Row Lock contention happens in a specific table.
This is the exception :
java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock
Already all the following properties have been set for openjpa.
1. <persistence-unit name="JPXA" transation-type="JTA">
2. <property name="openjpa.TransactionMode" value="managed"/>
You can try a plug-in string to lookup the TM in JNDI (the value is the JNDI name of GlassFish TM as per Google search)
3. <property name="openjpa.ManagedRuntime"
value="jndi(TransactionManagerName=java:appserver/TransactionManager)"/>
Following searching about this locking problem, we found that we should add two more properties for openjpa as listed below.
<property name="openjpa.LockManager" value="version" />
<property name="openjpa.jdbc.TransactionIsolation" value="read-committed" />
but this time by setting the transaction isolation level, we have got another error: org.apache.openjpa.persistence.PersistenceException: ORA-02089: COMMIT is not allowed in a subordinate session.
Thanks for any help.
Regards,
Sargol

How to change the transaction isolation level of a CMP?

How to change the transaction isolation level of a CMP from SUN's Deployment Tool? So far I can't find any entry for this setting.

Anuradha W wrote:
That means, currently the only way tospecify the transaction level is through
weblogic-ejb-jar.xml deployment descriptor?
for WLS-generated code, yes.Somewhat related to this question, we have written a standalone testcase to reproduce this issue we have been having. Basically, the issue is that even though we configure the isolation level to a non-default one in the deployment descriptor, the connections returned by the datasource seem to be having the default (which is Read Committed). The DBMS is DB2.
weblogic-ejb-jar.xml has the following set:
<isolation-level>TransactionRepeatableRead</isolation-level>
And we printed the isolation level of the connection returned from a method in the EJB, but the isolation level is still the default. I can share the code to reproduce the problem if you want to take a look at it. Please let me know how I can get that across to you.
Thanks,
AnuradhaIf you are using our JDBC driver for DB2, or can switch to it,
just for a test, there is some debug I'd like from you.
Joe

How to Set the Transaction Isolation Level in WebLogic?

Is there a way to set the transaction isolation level in WebLogic 9.2 or WebLogic 10?
For an example say, we have an application which is supported for several database platforms. Without setting the transaction isolation level in DBMS level, is there a way to specify this in WebLogic to make it common for all the DBMS type?
And I found a way to change the transaction isolation level in WebSphere application server using a property called webSphereDefaultIsolationLevel.
[url http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21224492]http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21224492
Is there a way to do the same thing in WebLogic application server 9.2 or 10?

Anuradha W wrote:
That means, currently the only way tospecify the transaction level is through
weblogic-ejb-jar.xml deployment descriptor?
for WLS-generated code, yes.Somewhat related to this question, we have written a standalone testcase to reproduce this issue we have been having. Basically, the issue is that even though we configure the isolation level to a non-default one in the deployment descriptor, the connections returned by the datasource seem to be having the default (which is Read Committed). The DBMS is DB2.
weblogic-ejb-jar.xml has the following set:
<isolation-level>TransactionRepeatableRead</isolation-level>
And we printed the isolation level of the connection returned from a method in the EJB, but the isolation level is still the default. I can share the code to reproduce the problem if you want to take a look at it. Please let me know how I can get that across to you.
Thanks,
AnuradhaIf you are using our JDBC driver for DB2, or can switch to it,
just for a test, there is some debug I'd like from you.
Joe

Why encounter errors while setting transaction isolation level?

When attempting to set the transaction isolation level within an EJB, I encountered the following exception from the server log:
===========================================================
[#|2006-05-30T15:08:45.906+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
Enter ejbCreate( 100, Duke, Earl, 0.00 ):|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
List of Supported Transaction Isolation Levels: |#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
TRANSACTION_READ_UNCOMMITTED is supported!|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
TRANSACTION_READ_COMMITTED is supported!|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
TRANSACTION_REPEATABLE_READ is supported!|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
TRANSACTION_SERIALIZABLE is supported!|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
1. |#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|Transaction Status: |#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|TRANSACTION_READ_COMMITTED|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
con.isReadOnly() = false|#]
[#|2006-05-30T15:08:45.937+0800|WARNING|sun-appserver-pe8.1_02|javax.enterprise.system.stream.err|_ThreadID=25;|
SQLException: java.sql.SQLException: Transaction manager errors. statement not allowed in XA session.|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=25;|EJB5018: An exception was thrown during an ejb invocation on [SavingsAccountBean]|#]
[#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=25;|
javax.ejb.EJBException: ejbCreate: Unable to connect to database. Transaction manager errors. statement not allowed in XA session.
at SavingsAccountBean.ejbCreate(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.enterprise.security.SecurityUtil$2.run(SecurityUtil.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.security.application.EJBSecurityManager.doAsPrivileged(EJBSecurityManager.java:950)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:158)
at com.sun.ejb.containers.EJBHomeInvocationHandler.invoke(EJBHomeInvocationHandler.java:170)
at $Proxy60.create(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:123)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:648)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1709)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1569)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:951)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:721)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:469)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1258)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:409)
|#]===========================================================
But from the above log messages, all transcation isolation levels are supported. The relevant source codes are:
/*********************** Database Routines *************************/
private void makeConnection() {
try {
InitialContext ic = new InitialContext();
DataSource ds = ( DataSource )ic.lookup( dbName );
con = ds.getConnection();
DatabaseMetaData dmd = con.getMetaData();
show_supported_trans_levels( dmd );
int status = con.getTransactionIsolation();
System.out.print( "1. " );
disp_tx_status( status );
System.out.println( "con.isReadOnly() = " + con.isReadOnly() );
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
System.out.print( "2. " );
disp_tx_status( status );
} catch( SQLException ex ) {
System.err.println( "SQLException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
} catch( NamingException ex ) {
System.err.println( "NamingException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
private void disp_tx_status( int status )
System.out.print( "Transaction Status: " );
switch( status )
case( Connection.TRANSACTION_READ_UNCOMMITTED ):
System.out.println( "TRANSACTION_READ_UNCOMMITTED" );
break;
case( Connection.TRANSACTION_READ_COMMITTED ):
System.out.println( "TRANSACTION_READ_COMMITTED" );
break;
case( Connection.TRANSACTION_REPEATABLE_READ ):
System.out.println( "TRANSACTION_REPEATABLE_READ" );
break;
case( Connection.TRANSACTION_SERIALIZABLE ):
System.out.println( "TRANSACTION_SERIALIZABLE" );
break;
case( Connection.TRANSACTION_NONE ):
System.out.println( "TRANSACTION_NONE" );
break;
default:
System.out.println( "UNKNOWN" );
break;
Who can help me?

Try the following forum (about EJB technology)
http://forum.java.sun.com/forum.jspa?forumID=13

Why can't I change the transaction isolation level?

I was trying to change the transaction isolation level from an EJB. My source codes are shown as the follows:
======================================================
/*********************** Database Routines *************************/
private void makeConnection() {
try {
InitialContext ic = new InitialContext();
DataSource ds = ( DataSource )ic.lookup( dbName );
con = ds.getConnection();
DatabaseMetaData dmd = con.getMetaData();
show_supported_trans_levels( dmd );
int status = con.getTransactionIsolation();
System.out.print( "1. " );
disp_tx_status( status );
System.out.println( "con.isReadOnly() = " + con.isReadOnly() );
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
System.out.print( "2. " );
disp_tx_status( status );
} catch( SQLException ex ) {
System.err.println( "SQLException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
} catch( NamingException ex ) {
System.err.println( "NamingException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
private void disp_tx_status( int status )
System.out.print( "Transaction Status: " );
switch( status )
case( Connection.TRANSACTION_READ_UNCOMMITTED ):
System.out.println( "TRANSACTION_READ_UNCOMMITTED" );
break;
case( Connection.TRANSACTION_READ_COMMITTED ):
System.out.println( "TRANSACTION_READ_COMMITTED" );
break;
case( Connection.TRANSACTION_REPEATABLE_READ ):
System.out.println( "TRANSACTION_REPEATABLE_READ" );
break;
case( Connection.TRANSACTION_SERIALIZABLE ):
System.out.println( "TRANSACTION_SERIALIZABLE" );
break;
case( Connection.TRANSACTION_NONE ):
System.out.println( "TRANSACTION_NONE" );
break;
default:
System.out.println( "UNKNOWN" );
break;
private void show_supported_trans_levels( DatabaseMetaData dmd ) throws SQLException
System.out.println( "List of Supported Transaction Isolation Levels: " );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_UNCOMMITTED ) )
System.out.println( "TRANSACTION_READ_UNCOMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_UNCOMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_COMMITTED ) )
System.out.println( "TRANSACTION_READ_COMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_COMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_REPEATABLE_READ ) )
System.out.println( "TRANSACTION_REPEATABLE_READ is supported!" );
else
System.out.println( "TRANSACTION_REPEATABLE_READ is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_SERIALIZABLE ) )
System.out.println( "TRANSACTION_SERIALIZABLE is supported!" );
else
System.out.println( "TRANSACTION_SERIALIZABLE is unsupported!" );
=========================================================
However, I encountered the following exception when running at the highlighted statement:
======================================================
SQLException: java.sql.SQLException: Transaction manager errors. statement not allowed in XA Session.
======================================================
To my surprise, the isolation level TRANSACTION_SERIALIZABLE is supported from the database vendor. So why can't I change the transaction isolation level?

You can change the setting, you may need to click the lock at the bottom of the preference pane. Be careful what you download and install, Gatekeeper is there to help you. OS X: About Gatekeeper - Apple Support

Setting transaction isolation level in a session bean

Hi all!
In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
The idea is to prevent lost update on database when multiple accesses occur concurrently.
Thanks in advance for your patience,
Tommaso

Hi all!
In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
The idea is to prevent lost update on database when multiple accesses occur concurrently.
Thanks in advance for your patience,
Tommaso

Transaction Isolation Levels in weblogic-cmp-rdbms-jar.xml

Hi All,
Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
isolation levels for the methods in the
weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
the isolation levels in these two ways.
Help me asap.

The CMP setting has been deprecated. You can set it for all types of
EJBs in the weblogic-ejb-jar.xml
-- Rob
chandru wrote:
Hi All,
Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
isolation levels for the methods in the
weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
the isolation levels in these two ways.
Help me asap.

Default transaction isolation level

Similar Messages

Maybe you are looking for