Isolation Level in Distributed Transaction

Hi All,
I setup a distributed transaction with a Serializable isolation level.
When the OracleConnection enlists the distributed transaction I have read-commited isolation on Oracle allowing the transaction to perform inconsistent reads.
Is the Oracle Provider ignoring the distributed transaction isolation level?
How can I make the provider set the appropriate isolation level?
Thanks a lot,
BMoscao

Hi,
i've got the same problem.
Could you solve it?
thanks

Similar Messages

What's the Isolation Level of account transaction

SERIALIZABLE or READ COMMITED ?

Take a look to a Tom Kyte's article into OraMag : On Transaction Isolation Levels
Nicolas.

Can you set isolation levels of message-driven bean transactions?

The problem: I have 3 different message-driven beans which each get a different type of message, except for a field that is common to all. That field is used as the primary key of an entity object. The message-driven beans configured to use a container managed transaction. Each message-driven bean, in processing the message, first does a lookup by primary key to see if the object associated with the key exists, and if it does not, it requests the entity's home object to create it. After that, they do further processing. The problem is that sometimes all the beans simultaneously get a message, resulting in each bean checking for the entity object at about the same time, and if they fail to find it (because none of them has created it yet), each creates an object, all with the same primary key. This is not caught until the beans start to complete their onMessage method, which I believe results in the container committing the transaction. One of the transactions will be committed successfully, while the other two will fail, get rolled back, and then be retried with the same message. The second time through, the other beans will find the entity object (since it has been created and committed) and they will complete correctly. In the end, they right thing occurs, except that there is a troubling exception or 2 in the log telling about the constraint violation (with the primary key) and the rollback. If it was just me, that would be fine, but our customer does not like to see exceptions in the log; that indicates to him that something is wrong.
So, I am looking for someway to make sure that the actions of the message-driven beans are serialized. One suggestion from a colleague was to set the isolation level of the transactions being used by the container in processing the message-driven beans' onMessage method. However, the documentation does not mention any way to do this for a message-driven bean. Suggestions?
Is the use of a UserTransaction a better way to do this? If I acquire a UserTransaction within the onMessage method of a message-driven bean, can I set its isolation level? How would this work? When I get a UserTransaction, does each client get a different transaction, or do they all get the same one?

(1) The WebLogic JMS "unit-of-order" feature is a heavily adopted feature that was specifically designed to handle similar use cases - see the JMS developer guide for extensive documentation. In your use case, if "key" is used to define UOO, then there's no limit on the number of keys that can be processed concurrently, but messages for any particular key will be processed single-threaded in the order in which they were first submitted.
Note that if you're using distributed destinations, the UOO feature is still fully supported - but the developer and/or administrator needs to decide whether to configure the destination to use "hash" or "path service" based routing (the JMS UOO edoc outlines the trade-offs).
(2) Another alternative is to use a single MDB with max-beans-free-pool that processes all three types (as the other poster suggested). I think this assumes all MDBs run on the same JVM.
(3) Another alternative is to use multiple queues, with a single MDB on each Q. Where some sort of hash algorithm is used to determine which Q is for the key. This approach is a "hand-coded" variant of the approach in (1) with "hash" based routing enabled...
(4) If all MDBs actually do run in the same JVM, a third alternative is to use code the application to use a common lock to protect each key, eg, something like:
// assume MyLock is simply a class with a "reference counter"
// assume some global "staticHM" hash map that is all MDBs can access
onMessage() {
MyLock lock = null;
key= msg.getKey();
synchronized(staticHM) {
lock = staticHM.get();
if (lock = null) {
lock = new lock();
staticHM.put(key, new lock());
lock.incRefCount();
try {
synchronized(lock) {
// only one onMessage will be able to lock a particular key at a time
do your work;
} finally {
synchronized(staticHT) {
if (lock.defRefCount() == 0) staticHM.remove(lock);
if (lock = null) staticHM.put(key);
If multiple threads get a message with the same key, then only one thread at a time will work on the key.
Hope this helps,
Tom

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?

How to set Transaction isolation level in Weblogic 11g

How do I set the transaction isolation level in Weblogic?
Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
Can I set this up as a property in the JDBC datasource setup?
Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
Currently I get the following message if I don't set the isolation level:
Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
I think the issue is related to the isolation level or the transaction time out being too low.
Any ideas?
BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
Thanks
Edited by: rrivera on Jun 2, 2010 9:18 AM

How do I set the transaction isolation level in Weblogic?
Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
Can I set this up as a property in the JDBC datasource setup?
Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
Currently I get the following message if I don't set the isolation level:
Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
I think the issue is related to the isolation level or the transaction time out being too low.
Any ideas?
BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
Thanks
Edited by: rrivera on Jun 2, 2010 9:18 AM

Setting XA isolation level.

Is there a configuration parameter that controls the default isolation level used by distributed transactions when you configure XA support on Oracle 8i? I know Oracle's default isolation level is READ COMMITTED, but I would like to have SERIALIZABLE as the isolation level for transactions that are initiated from some MS COM+ components accessing the database.
Thanks,
Sam

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?

How do you determine a process or sessions isolation level.

We are using COM+ components to issue database statements against an Oracle 8i database. COM+ has a property that allows you to set the isolation level. Is there any tool or query that would allow me to verify the isolation level in use by a session or process? I want to verify this property is actually affecting the connection to the DB.
Thanks,
Sam

FLAG is just one of those columns that Oracle uses. It isn't documented but, as far as I know (which isn't very far), the only use for it is to record the isolation level for the transaction.
I didn't mention it because I didn't think it helped you, for this reason: we don't get a record in the v$transaction view until the transaction has already started. At which point it is too late to change the ISOLATION_LEVEL for the transaction.
Although I suppose you could do this:
BEGIN
   UPDATE dummy_table set col1 = col1;
   -- remember V$TRANSACTION shows all txns
   SELECT count(1) INTO ln
   FROM   v$transaction t, v$session s
   WHERE bitand(t.flag,268435456) <> 0
   AND    s.taddr = t.addr
   AND    s.audsid = sys_context('userenv', 'sessionid');
   IF ln = 0
   THEN
      ROLLBACK;
      SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   END IF;
   -- do_whatever
   COMMIT;
END ;.
Cheers, APC

Setting isolation level with JDriver for 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? Is this determined by some database setting?

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? Is this determined by some database setting?The system should honor the setting defined in the deployment descriptor,
however, for oracle it may not be helpful to change it. Oracle provides two
isolation levels. The default is always READ_COMMITTED. The other
setting is SERIALIZABLE, but this hurts performance, and is also problematic
in the way oracle implements it. For instance, even if you set SERIALIZABLE,
oracle will not lock read data. It will allow other transactions to read and/or
alter data trhat another ongoing SERIALIZABLE transaction has read. The
only way to really lock read data in oracle is to issue oracle-specific SQL in
your select: "SELECT ..... FOR UPDATE".
All in all, you should collect a strong case for why you can't proceed with
READ_COMMITTED first. Then you should research oracle's recommendations
(and their problem record) with SERIALIZABLE.
Joe Weinstein at BEA

Setting Isolation Level In A UserTransaction

We are having a problem where a class creates a UserTransaction from the InitialContext,
but does not see any database changes made by other EJBs even though they have
been committed. This "seems" like an isolation issue.
What is the default isolation level for UserTransaction? And since it appears
that it is not seeing committed data, what level should it be set to? (i.e. TRANSACTION_READ_COMMITTED
would be nice...)

this is mirrored from the transaction newsgroup:
Joseph Weinstein <[email protected]> wrote:
>
>
Interesting, but it's not an isolation level issue. There is no DBMS
isolation level
that could cause a user not to see already-committed data.Well, we are using Oracle as our backend and it supports Read Uncommitted, Read
Committed and Serializable. The Serializable option would prevent a transaction
from seeing any committed data to a table (i.e. prevents unrepeatable reads).
The default isolation level of most DBMSes is READ_COMMITTED, and you
should
never have to change it, and you should be able to see already-committed
data.I agree, but that is not happening for us (and this gets somewhat complicated
with JMS). What is Weblogic 8.1's default isolation level for any transaction.
From the link below, I get the impression it is SERIALIZABLE which would explain
the behaviour I'm seeing. Athough the article seems to be talking about CMT (container
transation), I would suspect a BMT (bean managed transaction) be similar (just
manual).
If this only confuses things, please let me know the easiest way to communicate
this issue (code, etc..)
http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.transaction&item=227&utag
(from the article)
Subject: Re: What is ths default transaction isolation level
Date: Mon, 12 Feb 2001 15:27:24 -0500
From: "Cameron Purdy" <[email protected]>
Organization: BEA SYSTEMS Inc
Newsgroup: weblogic.developer.interest.transaction
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 > defaulttransaction isolation level > Thanks > Jay > >

BMT - Setting Isolation Level

          (I posted this in ejb but didn't really get a solution that works)
          I'm able to set the isolation level of a CMT using weblogic-ejb-jar.xml without
          any problems. Below is a snipet which shows how that:
          <transaction-isolation> <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
          <method> <description><![CDATA[Transaction isolation for StateHandlerMessage]]></description>
          <ejb-name>StateHandlerMessage</ejb-name> <method-name>*</method-name> </method>
          </transaction-isolation>
          That works perfectly for a CMT bean, however it does not seem to work for a BMT.
          I'm using weblogic81 in development mode with an oracle jdriver and it seems my
          BMT bean is getting an isolation level of TRANSACTION_SERIALIZABLE.
          Is this a bug? If not how do I set the isolation level for a BMT bean? (I don't
          think I can using Connection.setIsolationLevel since I don't have a connection
          within my Session and Message Beans)
          thanks!
          lance


          But weblogic.transaction.Transaction does have setProperty method and you should
          be able to use :
          weblogic.transaction.TxHelper.getTransaction().setProperty() to set that property.
          "Lance" <[email protected]> wrote:
          >
          >Thanks for the reply, however javax.transaction.UserTransaction does
          >not have a
          >.setProperty method.
          >
          >Any ideas?
          >
          >lance
          >
          >"asafbu" <[email protected]> wrote:
          >>
          >>
          >>
          >>You set the isolation level for user transactions in the beans java
          >code.
          >>When
          >>the application runs, the transaction is explicitly started.
          >>
          >>
          >>User Transaction tx = (UserTransaction) ctx.lookup("javax.transaction.UserTransaction");
          >>
          >>tx.begin();
          >>
          >>tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
          >> (Connection.TRANSACTION_READ_COMMITED));
          >>....
          >>....
          >>
          >>
          >>
          >>
          >>
          >>"Lance" <[email protected]> wrote:
          >>>
          >>>(I posted this in ejb but didn't really get a solution that works)
          >>>
          >>>I'm able to set the isolation level of a CMT using weblogic-ejb-jar.xml
          >>>without
          >>>any problems. Below is a snipet which shows how that:
          >>>
          >>><transaction-isolation> <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
          >>><method> <description><![CDATA[Transaction isolation for StateHandlerMessage]]></description>
          >>><ejb-name>StateHandlerMessage</ejb-name> <method-name>*</method-name>
          >>></method>
          >>></transaction-isolation>
          >>>
          >>>That works perfectly for a CMT bean, however it does not seem to work
          >>>for a BMT.
          >>>I'm using weblogic81 in development mode with an oracle jdriver and
          >>it
          >>>seems my
          >>>BMT bean is getting an isolation level of TRANSACTION_SERIALIZABLE.
          >>
          >>>
          >>>Is this a bug? If not how do I set the isolation level for a BMT bean?
          >>> (I don't
          >>>think I can using Connection.setIsolationLevel since I don't have a
          >>connection
          >>>within my Session and Message Beans)
          >>>
          >>>thanks!
          >>>
          >>>lance
          >>>
          >>
          >

Set isolation level in EJB 2.0

how can i set isolation level to a transaction in EJB 2.0.
If anybody can give example code much appriciated

For 5.1, look at:
          http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#107261
          7
          http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_reference.html#1061916
          "marshalli" <[email protected]> wrote in message
          news:3a59546d$[email protected]..
          >
          > How to set the isolation level(Container Manager or Bean Manager) in EJB.
          Thanks
          >
          >

Isolation level SERIALIZABLE problem

Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure

Marcel,
First of all, I'd be interested in hearing why you think you need serializable transactions (why 'read committed' doesn't work for your application). In the 8 years I've been building Oracle apps, I've never deemed it necessary to use serializable transactions. Maybe an optimistic locking strategy will solve your problem.
Secondly, if I were designing the interface, I wouldn't have a procedure in charge of both executing business logic AND retrying the logic in case of failure. I'd build a helper procedure that calls the procedure that does the work, looks for certain exceptions, and retries the procedure when necessary.
Lastly, if your interface doesn't have transactional control (the caller is in charge of commits and rollbacks), maybe you should simply attempt the update statement and throw an exception to the caller and let them handle it.
I'm sorry if I haven't directly solved your problem, but sometimes the best way to solve a problem is to question the decisions that got you there in the first place.
Hi there,
I have a problem with my stored procedures when the isolation level of the connection is serializable. I need to set this isolation level because of data consistency reasons.
When in this isolation level and a transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began, I get this error:
ORA-08177: Cannot serialize access for this transaction
This is normal. The thing to do in this case is catch the error in the exception handler, rollback to a certain savepoint and try to do the update again.
The stored procedure that I use to test this is:
CREATE OR REPLACE PROCEDURE nm_test IS
tmpVar NUMBER;
err_num NUMBER;
err_msg VARCHAR2(200);
teller number;
BEGIN
teller := 0;
savepoint sp1;
<<try_every_thing_again>>
begin
tmpVar := 0;
update stock_prices set price = price + 1
where ric = 1;
DBMS_OUTPUT.Put_Line('teller = ' || teller);
EXCEPTION
WHEN others THEN
err_num := SQLCODE;
--err_msg := SUBSTR(SQLERRM, 1, 200);
     if (err_num = -8177) then
          rollback to savepoint sp1;
          --DBMS_LOCK.SLEEP(1);
          teller := teller + 1;
          if (teller < 10) then
               goto try_every_thing_again;
          end if;
          DBMS_OUTPUT.Put_Line('exception: teller = ' || teller);
     end if;
end;
END nm_test;
I test this using 2 connections to the database. In the first connection I run the stored proc (without committing). Then I run the same stored proc in the second connection. This will block on the update (the is an implicit lock), which is ok. Then I commit the first connection. The second catches the error, rolls back and tries the update again....but then it catches the exception again, and again???
When I replace the "rollback to savepoint" by just "rollback", everything works fine (the exception is then caught only once) and the update succeeds on the second try.
But I can not work with just a "rollback" because my stored procedures might be called by others for which I don't want to undo all the work.
Do any of you know why I keep getting this error (the program ends up in an infinite loop if I didn't keep a counter and exit after 10 times)?
Marcel van Vuure

Understanding isolation levels

I'm having a difficult time understanding isolation levels. I know what problems each isolation level solves (i.e. dirty reads, nonrepeatable reads, phantom reads) and the classic textbook description of each level, but I simply cannot understand how it works. Let me explain my understanding of the various isolation levels:
READ_UNCOMMITTED:
The data read by TX 1 is held in a read lock, correct? TX 1 modifies the data. TX 2 therefore can read that data (but cannot write to it, due to the read lock). TX 2 can therefore read uncommitted data.
READ_COMMITTED:
The data read by TX 1 is held in a write lock, correct? TX 1 modifies the data. TX 2 cannot read the data because of the write lock, hence solving the dirty read problem. It cannot read the data TX 1 has so much as read during the course of its transaction (true?).
REPEATABLE_READ:
This is the biggest source of my confusion. How is it that the nonrepeatable read problem is not solved by READ_COMMITTED? TX 1 reads some data, TX 2 cannot read that data due to the read lock...but somehow it manages to modify TX 1's data so that when TX 1 repeats its query, it gets different results? How is this possible? And apart from the read and write lock of the two previous isolation levels, what does the database do to enforce this new isolation level on top of the other two?
SERIALIZABLE:
TX 2 cannot do anything without TX 1 finishing. (But isn't this similar to READ_COMMITTED, whereby TX 2 cannot even read TX 1's data until it has committed.) What is being meant by sequential execution here?
I think a source of confusion is that I am unaware of whether isolation levels are applied to an entire database, to a transaction, to a query, or some other category. Can one transaction have one isolation level while another transaction has another isolation level?
Any insight into isolation levels would be appreciated. Thanks.

It depends upon the database implementation - there are various different ways to solve the problem.
I think a source of confusion is that I am unaware of whether isolation levels are applied to an entire database, to a transaction, to a query, or some other category.
By definition the isolation levels are applied to the transaction. Other transactions can have other isolation levels.

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

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.

Isolation Level in Distributed Transaction

Similar Messages

Maybe you are looking for