HSODBC - DB2 transaction isolation - uncommitted reads

Hi!
I need to be able to read uncommitted data on the DB2 side using HSODBC. We are running into contention when updates happen on the DB2 side at the same time that we are trying to read from Oracle side using HSODBC. If we set the transaction isolation level on the Oracle side will that be passed over to the DB2 side? Otherwise do we need to use DBMS_PASSTHRU, etc.?
Thanks for your help!
Dave Venus

HSODBC is designed to work only with commited read.

Similar Messages

Setting transaction isolation level on a replicated server stored procedure

I have a SQL server that has replication turned onto to another server which is our reporting server. Replication is real-time (or close to it). On the report server I have a stored procedure that runs from a SRS report. My question is it possible or advisable
or does it even make sense to set the "SET TRANSACTION ISOLATION LEVEL READ COMMITTED" on at the beginning of the stored procedure which selects data from the reporting server database? Is it possible for uncommitted data on the OLTP side of the
house to be replicated before it is committed? We are having data issues with a report and have exhausted all options and was wondering if dirty data maybe the issue since the same parameters work for a report 1 sec and then next it doesnt.

Only committed transactions are replicated to the subscriber. But it is possible for the report to see dirty data if running in READ UNCOMMITTED or NOLOCK. You should run your reports in READ COMMITTED or SNAPSHOT isolation , and your replication
subscriber should be configured with READ COMMITTED SNAPSHOT ISLOATION eg
alter database MySubscriber set allow_snapshot_isolation on;
alter database MySubscriber set read_committed_snapshot on;
as recommended here
Enhance General Replication Performance.
David
David http://blogs.msdn.com/b/dbrowne/

Transaction Isolation Levels

Hi Everyboody.
Oracle docs. say that Oracle supports three isolation levels and the isolation level should be set before the transaction begins with the SET TRANSACTION ISOLATION LEVEL .....
Resource: http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/server.920/a96524/c21cnsis.htm#2641
But I find that Oracle 9i supports only two isolation levels, viz. Read Committed and Serializable.
SQL> SET TRANSACTION ISOLATION LEVEL READ ONLY
2 ;
SET TRANSACTION ISOLATION LEVEL READ ONLY
ERROR at line 1:
ORA-02179: valid options: ISOLATION LEVEL { SERIALIZABLE | READ COMMITTED }
Is READ ONLY isolatin level avalilable in Oracle 9i or is there any problem with my SET instruction?
Please help me at the earliest.
Have a nice day!
Kishore

Thanks Dmitry.
It works.
Continuing on the same thread, I would like to know what is the difference between READ COMMITTED and SERIALIZABLE isolation levels?
Thank you for your reply.
Kishore.

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

Z/os db2 (type 2) transaction isolation from rr to cs, general questions

Let me preface this by saying I'm pretty uninformed when it comes to database transaction isolation and what it really means to my application. I've done some homework on the differences between the read committed (cs) and repeatable read (rs) but still a little fuzzy.
App stats: Mainframe z/os db2 v8 (type 2 driver), WAS 6.0.x.x The app runs with about 80000 concurrent users (using about 150-200 JDBC connections in the pool).
I found this which held some good information: http://forum.java.sun.com/thread.jspa?forumID=48&threadID=586570 but it leaves me with some questions still.
Our Mainframe dba is saying he sees a lot of locking (not dead locks, just locks) and it is eating up the MIPS. He told us to set our transaction isolation level to cs to reduce the locking db2 does. But I don't know enough about this to make a good decision. The general consenus I've gotten from various forums (spring, hibernate) is that using CS will cause more problems than it will fix.
The only sql error I see in our logs is due to an insert or update to a FK being invalid. I suppose this could cause some locking problems but would this cause deadlocks?
If anyone can provide some links to explain this, I'd be really appreciative. Or if you have any first hand knowledge -- even better.
Thanks for your time.

I am also not an expert and haven't used DB/2 on z/OS but am using it on OS/400. I think your DBA is confused.
From what I have experienced setting commit control to CS causes more locking than RS. From what I can determine (which has been through trial and error so it may not be totally accurate) CS causes the database to exclusive lock all records in the cursor while RS will use shared locks. I do know from painful experience that if you set all your transactions to CS you will experience frequent update problems due to record locks. We had to go through and set everything to RS and, once we did, our concurrency problems were nearly eliminated. There are some instances that you have to use *CS, however, such as when a stored procedure returns a cursor, but the compiler will tell you about this.
Another thing that doesn't make sense is locks are typically implemented as data structures in memory and do not require much if any processor time. I don't know the specifics of DB/2 implementation but Oracle uses simple semaphores, so I would assume IBM does, too.
Also, from my experience, there appears to be no way around DB/2 locking. Having come from an Oracle background I find the amount of locking DB/2 does totally frustrating. It's not as bad as SQL Server but can become problematic at times. That is just my $.02 anyway.

Issues with transaction isolation levels (BEA-631 exceptions)

My intended EJB application will have a session bean that uses two very similar entity beans that will be mapped to different databases; in my test version the entity beans use the same database.
The final application will need XA transactions with isolation=serializable (beans may be in Oracle, DB2, or MSSQL databases); high probability of concurrent potentially interfering transactions.
My test example works (Windows XP, WebLogic 8.1, Oracle 9.2) with both BEA's Oracle driver, and the Oracle driver but only when I set a transaction isolation on the session bean as the Oracle specific "transactionreadcommitedforupdate".
If I try using "transactionserializable", I get an exception like the following when my session-bean first tries to find an entity bean:
<2/09/2005 10:13:43 AM EST> <Warning> <Common> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1f13e99" being released to pool "BEAOraclePool". Printing out current pool contents.>
(similar response with both drivers).
Please could someone explain what is wrong and why setting isolation serializable causes problems. How
should I fix things?

Hi. What version of 8.1 is this?
If you can easily reproduce this
we may either have a fix, or will
want to debug this.
Joe
Neil Gray wrote:
The bit about "cleaning up vendor connections" was from the comment by Imeshev that was earlier in this thread.
The context:
Application does involve possibility of two concurrent transactions trying to change the same row of a datatable; as isolation level is repeatableread or serializable, this will result in some exceptions. Sometimes exceptions handled ok, sometimes they cause problems.
Particular case illustrated below is when working with DB2. As I understand it, the two concurrent EJBs both make read requests (presumably acquiring read locks) then make update requests - if they happen to share a row this will block. I don't know enough about DB2 to know what controls its detection of problems. In practice I see db2 typically sending back an error to one of requestors in less than 1 second, but sometimes several seconds may elapse before the error response gets sent (I have observ
ed actual net traffic).
If transaction gets timed out in WebLogic (I've curently got a generous 8 second timeout setting in JTA tab) then there are problems.
First of two exceptions shown here is for normal case where db2 returned an error and it was handled ok:
11111111111111111
####<30/09/2005 10:55:39 AM EST> <Error> <EJB> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-010026> <Exception occurred during commit of transaction Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-1D5B56A9177C58E3D95B(17477508),Status=Rolled back. [Reason=weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=10,XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=rolledback,assigned=examplesServer),xar=BEADB2,re-Registered = false),SCInfo[examples+examplesServer]=(state=rolledback),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.Bi
gDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@eed1b8]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+): weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.
     at weblogic.jdbc.db2.DB2ImplStatement.executeBatch(Unknown Source)
     at weblogic.jdbc.base.BaseStatement.commonExecute(Unknown Source)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]
     at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:673)
     at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1010)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion: sync=weblogic.ejb20.internal.TxManager$TxListener@eed1b8
Error writing from beforeCompletion - with nested exception:
[weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - with nested exception:
[weblogic.jdbc.base.BaseBatchUpdateException: [BEA][DB2 JDBC Driver]Abnormal end unit of work condition occurred.]]
     at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
.>
222222222222222
Second case is where timeout in WebLogic occurred (I think) which leads to something messing up the connection pool
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <BEA1-22BE56A9177C58E3D95B> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1551d57" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@1551d57" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Warning> <Common> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-000631> <Unknown resource "weblogic.jdbc.common.internal.ConnectionEnv@f95d4a" being released to pool "BEADB2". Printing out current pool contents.>
####<30/09/2005 10:56:24 AM EST> <Error> <EJB> <ATP-NL2-RS3> <examplesServer> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-010026> <Exception occurred during commit of transaction Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=9,seconds left=9,XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=rolledback,assigned=examplesServer),xar=BEADB2,re-Registered = false),SCInfo[examples+examplesServer]=(state=rolledback),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4})
,local properties=({modifiedListeners=[]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+): weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)
     at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1614)
     at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1117)
     at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1881)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+) - with nested exception:
[weblogic.transaction.internal.TimedOutException: Transaction timed out after 8 seconds
Name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)],Xid=BEA1-22BD56A9177C58E3D95B(18185360),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=8,seconds left=10,activeThread=Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[BEADB2]=(ServerResourceInfo[BEADB2]=(state=started,assigned=none),xar=BEADB2,re-Registered = false),SCIn
fo[examples+examplesServer]=(state=pre-preparing),properties=({weblogic.transaction.name=[EJB db2transferapp.TransferBean.doTransfer(java.lang.String,java.lang.String,java.math.BigDecimal)], ISOLATION LEVEL=4}),local properties=({modifiedListeners=[weblogic.ejb20.internal.TxManager$TxListener@1f2a681], weblogic.jdbc.jta.BEADB2=weblogic.jdbc.wrapper.TxInfo@1a4ef37}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+, XAResources={},
NonXAResources={})],CoordinatorURL=examplesServer+203.143.168.208:7001+examples+t3+)]
     at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1683)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:325)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
.>
Once start getting those things released to pool the application falls apart. Shortly afterwards it loses all connections to DB2 (and DB2 may be left with some locks on the table that have to be cleared).
It isn't DB2 specific, if needed I can supply similar data for MSSQL server (BEA or MS drivers)

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

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

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.

Setting transaction isolation level in Weblogic 5.1

          Hi,
          I'm using Weblogic server5.1 and i'm trying to set the isolation level on one
          of my session bean. Below is the code :
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>chargeMgr</ejb-name>
          <jndi-name>chargeMgr</jndi-name>
          <transaction-isolation>
          <isolation-level>Serializable</isolation-level>
          <method>
          <ejb-name>chargeMgr</ejb-name>
          <method-intf>Remote</method-intf>
          <method-name>*</method-name>
          </method>
          </transaction-isolation>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          I have checked the syntax against the weblogic documentation.
          However, when i try to jar the beans up into the jar file (weblogic.ejbc), it
          give me the following error :
          org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean" allows no further
          input; "transaction-isolation" is not allowed.
          Can anyone help?
          Regards.


yes, only in weblogic-ejb-jar.xml , and you can see that from the DTD
          source.
          thanks
          Yu
          "cw lee" <[email protected]> wrote in message
          news:[email protected]...
          >
          > thanks for ur advice.
          >
          > one thing i forgot to mention is that the isolation-level was specified in
          weblogic-ejb-jar.xml.
          > Do u mean that it must be placed in weblogic-cmp-rdbms-jar.xml and not
          weblogic-ejb-jar.xml
          > ?
          >
          > Are the codes u suggested to be in weblogic-ejb-jar.xml or
          weblogic-cmp-rdbms-jar.xml
          > ?
          >
          > Regards.
          >
          >
          >
          > "Yu Tian" <[email protected]> wrote:
          > >the right name for Seriealizable should be: TRANSACTION_SERIALIZABLE.
          > >so the
          > >DD looks like:
          > >
          > ><?xml version="1.0"?>
          > >
          > ><!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic
          > >5.1.0
          > >EJB//EN' 'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>
          > >
          > ><weblogic-ejb-jar>
          > > <weblogic-enterprise-bean>
          > > <ejb-name>containerManaged</ejb-name>
          > > <caching-descriptor>
          > > <max-beans-in-cache>1000</max-beans-in-cache>
          > > </caching-descriptor>
          > > <persistence-descriptor>
          > > <persistence-type>
          > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
          > > <type-version>5.1.0</type-version>
          > > <type-storage>META-INF/weblogic-cmp-rdbms-jar.xml</type-storage>
          > > </persistence-type>
          > > <persistence-use>
          > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
          > > <type-version>5.1.0</type-version>
          > > </persistence-use>
          > > </persistence-descriptor>
          > > <jndi-name>containerManaged.AccountHome</jndi-name>
          > > <transaction-isolation>
          > > <isolation-level>TRANSACTION_SERIALIZABLE</isolation-level>
          > > <method>
          > > <ejb-name>containerManaged</ejb-name>
          > > <method-name>*</method-name>
          > > </method>
          > > </transaction-isolation>
          > > </weblogic-enterprise-bean>
          > > </weblogic-ejb-jar>
          > >
          > >Thanks
          > >
          > >Yu
          > >
          > >
          > >"cw lee" <[email protected]> wrote in message
          > >news:[email protected]...
          > >>
          > >> Hi,
          > >>
          > >> I'm using Weblogic server5.1 and i'm trying to set the isolation level
          > >on
          > >one
          > >> of my session bean. Below is the code :
          > >>
          > >> <weblogic-ejb-jar>
          > >> <weblogic-enterprise-bean>
          > >> <ejb-name>chargeMgr</ejb-name>
          > >> <jndi-name>chargeMgr</jndi-name>
          > >> <transaction-isolation>
          > >> <isolation-level>Serializable</isolation-level>
          > >> <method>
          > >> <ejb-name>chargeMgr</ejb-name>
          > >> <method-intf>Remote</method-intf>
          > >> <method-name>*</method-name>
          > >> </method>
          > >> </transaction-isolation>
          > >> </weblogic-enterprise-bean>
          > >> </weblogic-ejb-jar>
          > >>
          > >> I have checked the syntax against the weblogic documentation.
          > >> However, when i try to jar the beans up into the jar file
          (weblogic.ejbc),
          > >it
          > >> give me the following error :
          > >>
          > >> org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean"
          allows
          > >no further
          > >> input; "transaction-isolation" is not allowed.
          > >>
          > >> Can anyone help?
          > >>
          > >> Regards.
          > >>
          > >
          > >
          >

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.

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 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

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?

HSODBC - DB2 transaction isolation - uncommitted reads

Similar Messages

Maybe you are looking for