Isolation level and optimist/pessimist locking

I am using baen managed transaction in which i have set the isolstion level according to my use...
Now whrer does the concept of Optimist/pessimist locking comes if i have set the isolation level(it should be always pessimist locking in this case??) ???

Similar Messages

Comparison and implications of Informix vs Oracle isolation levels and read consisten

We are migrating from Informix 7x to Oracle 9i. Does anyone have information regarding differences in Isolation Levels and read consistency methodologies of the 2 products and how this might influence application coding changes.
Thanks!
Dick

I would not touch Hibernate with a 10ft barge pole.
The best in Oracle, is standard pessimistic locking, using the default transaction isolation level.
However, this requires stateful client-server.
Web-based client-server is stateless. Which means optimistic locking is the only viable alternative. 3 choices with optimistic locking. Check each every row column for a row update/change. Add a version column to the row and compare before and after version numbers when updating. Checksum the row before and after and confirm the checksums are the same.
You need a keyboard, a bit of a brain, and some basic code to implement one of these as an optimistic locking interface for stateless client-server. Not Hibernate.

Locking Mechanism/Isolation Level with Datastore (Pessimistic) Tr ansactions

What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?
Does the locking mechanism differ across database platforms? I had read
that only shared locks would be used on Microsoft SQL Server.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic transactions?
Thanks,
Sasha Haghani.

What type of locking is Kodo JDO performing in datastore (pessimistic)
transaction mode? Is a TRANSACTION_SERIALIZABLE isolation level being
specified when the connection is obtained or is SELECT FOR UPDATE being
used?Kodo sticks with the default isolation level of the JDBC driver in use
for transactions, as we've found that many drivers act up when assigned
a level manually.
To lock records during pessimistic transactions, SELECT FOR UPDATE is
used. For the most part, it gives good object-level locking, preventing
concurrent modification, even in applications that span multiple JVMs.
Does the locking mechanism differ across database platforms?The locking differs across databases only in that some DBs do not
support SELECT FOR UPDATE (in which case it is still possible to get
optimistic lock exceptions during pessimistic transactions), some DBs
use a different mechanism (SQLServer has a shared lock construct that is
just as good if not better), and some DBs place restrictions on its use
(Oracle and PostgreSQL cannot lock rows when a SELECT DISTINCT is used).
See the 'known bugs and limitations' appendix of the Kodo user guide for
a detailed listing of locking issues with each databse.
Also, what is the JDOLOCKX column generated by the schematool used for?
Does it contain a counter or timestamp used during optimistic
transactions?The lock column contains a counter to keep track of object versions. As
you suspect, it is used so that during optimistic transactions when no
locking is performed (or during pessimistic transactions on DBs or
queries that can't perform locking), the system is able to detect that
concurrent modification of an object has occurred and throw the proper
exception. This way data integrity is never lost, even without locking.
As an aside, you can always view the SQL generated by Kodo (and by
looking at it get a feel for how the various table columns are used,
etc) by setting a print writer in the
JDBCPersistenceManagerFactory.setLogWriter() method. Kodo will echo all
SQL to the given stream.
Happy coding.
-- Abe White
TechTrader

Isolation level and performance impact?

Hi
I'm new to BDB JE and building some prototypes to evaluate it.
Given a simple usecase of storing the following key/value pair <String,List<Event>> mapping a user to his/her list of events, in the db. New events are added for the user, this happens (although fairly rarely) concurrently.
Using Serializable isolation will prevent any corruption to the list of events, since the events are effectively added serially to the user. I was wondering:
1. if there are any lesser levels of isolation that would still be adequate
2. using Serializable isolation, is there a performance impact on updating users non concurrently (ie there's no lock contention since for the majority of cases concurrent updates won't happen) vs the default isolation level?
3. building on 2. is there performance impact (other than obtaining and releasing locks) on using transactions with X isolation during updates of existing entries if there are no lock contention (ie, no concurrent updates) vs not using transactions at all?
Thanks!
Peter

Have you seen this section of the Getting Started Guide on isolation levels in JE? http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/isolation.html
Our default is Repeatable Read, and that could be sufficient for your application depending on your access patterns, and the semantic sense of the items in your list. I think you're saying that the data portion of a record is the list of events itself. With RepeatableRead, you'll always see only committed data, and retrieving that record from a JE database will always return a consistent view of a given list. See http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/isolation.html#serializable for an explanation of what additional guarantee you get with Serializable.
2. using Serializable isolation, is there a
performance impact on updating users non concurrently
(ie there's no lock contention since for the majority
of cases concurrent updates won't happen) vs the
default isolation level?Yes, there is an additional cost. When using Serializable isolation, additional locks are taken on adjacent data records. In addition to the cost of acquiring the lock (which would be low in a non-contention case), there may be additional I/O needed to fetch adjacent data records.
3. building on 2. is there performance impact (other
than obtaining and releasing locks) on using
transactions with X isolation during updates of
existing entries if there are no lock contention (ie,
no concurrent updates) vs not using transactions at
all? In (2) we compared the cost of Serializable to RepeatableRead. In (3), we're comparing the cost of non-transactional access to the default Repeatable Read transaction.
Non-transactional is always a bit cheaper, even if there is no lock contention. On top of the cost of acquiring the locks, non-transactional operations use less memory and disk space, and execute some transaction setup and teardown code. If there are concurrent operations, even in there is no contention on a given lock, there could be some stress on the lock table latches and transaction tables. That said, if your application is I/O bound, the cpu differences between non-txnal and txnal operations becomes more of a secondary factor. If you're I/O bound, the memory and disk space overhead does matter, because the cache is more efficiently used with non-txnal operations.
Regards,
Linda
>
Thanks!
Peter

Jdbc mysql "select ... for update" and isolation level...

Dear, I am now writing an application, in which some worker threads will get a waiting job from database (mysql) and perform the processing.
To avoid workers getting the same job id, I have studied the topics about locks, isolation level, and something like "select ... for update".
The storage engine being used is innoDB. Actually the problem seems solved after using "select ... for update" to get the id, but I am just curious that do I also need to care about the isolation level. It is because when I do some experiments by setting the isolation level to serializable, but NOT using "SELECT ... FOR UPDATE" (just simple select), exception something like "deadlock found and try to restart transaction" occurs. Is there any relationship between these two things? Any comments are welcome!! Thanks!!!

ashipj wrote:
can u plz provide me with the code (connection string). Am new to Mysql.
And also the driver u are using.
Thank youDon't hijack other's topics. Kindly start your own. Don't do that before you read the [Sun JDBC tutorial|http://java.sun.com/docs/books/tutorial/jdbc/index.html] and the [MySQL JDBC documentation|http://dev.mysql.com/doc/refman/5.0/en/connector-j.html].

Oracle XA driver and isolation level

We have an Entity EJB that has isolation level specified in its
deployment descriptor and everything works fine if we use the non-XA
Oracle 9i driver.
However when we use the Oracle 9i Release 2 XA driver we get the
following exception:
java.sql.SQLException: Due to vendor limitations, setting transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
at
weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126)
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
at weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
at
weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.java:173)
at
weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164)
Note the 8.1.7 version that the container prints. The driver is
definitely 9i and not 8.1.7 and it's the very first thing in the classpath.
Is this a problem with the driver really or is it a WLS issue?
Thanks,
Dejan

Hi,
I removed the transaction isolation level setting from the deployment
descriptor and it works now as expected.
But in the meanwhile I also ran a test by using the driver directly
without Weblogic and I was able to successfully set the transaction
isolation level on the XA connections so I believe it's a Weblogic problem.
Dejan
Deyan D. Bektchiev wrote:
Yes,
We know about this but we just try to set it to the default one
(READ_COMMITED) which is probably redundant for Oracle but might not
be the default one for another DB vendor.
Here is the part of the deployment descriptor:
<transaction-isolation>
<isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
<method>
<ejb-name>Event</ejb-name>
<method-name>*</method-name>
</method>
</transaction-isolation>
Dejan
Slava Imeshev wrote:
Deyan,
I'm not 100% sure, but AFAIR oracle doesn't support all isolation
levels.
Which level do you set? Could you show us this part of the deployment
descriptor?
Slava
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
Thanks for the reply Sree,
Yes the 9i driver is the very first thing in the classpath as otherwise
we wouldn't even be able to connect to the 9i database with the 8.1.7
driver (we were getting lots of other exceptions when we were still
using the 8.1.7 driver).
I'll try removing the setting of the isolation level and I'll post the
result to the newsgroup.
Dejan
Sree Bodapati wrote:
hi Deyan,
java.sql.SQLException: Due to vendor limitations, setting
transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
should not have showed up with wrong version of oracle. If you can
verifiy
that the thin driver is the first thing in the classpath and you are
indeed
using the thin driver, This is a bug.
But in this case it looks like you need to remove the
TransactionIsolation
level from the EJB descriptor to get this to work. can you try that? I
will
forward this to one of our EJB engineers and see if we can get some
help
for
you.
sree
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
Sree,
We already did but the only answer we got was that the Oracle 9i
Release
2 driver was not at all supported by Weblogic 7.0 SP1.
But the certification page says that it is even certified...
So which one is true: The Oracle 9i Release 2 driver is not
supported or
is supported?
--dejan
Sree Bodapati wrote:
Please file a support case for this at [email protected]
"Deyan D. Bektchiev" <[email protected]> wrote in message
news:[email protected]...
We have an Entity EJB that has isolation level specified in its
deployment descriptor and everything works fine if we use the
non-XA
Oracle 9i driver.
However when we use the Oracle 9i Release 2 XA driver we get the
following exception:
java.sql.SQLException: Due to vendor limitations, setting
transaction
isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
at
weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126
at
weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
at
weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
at
weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.jav
a
>
173)
at
weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164
Note the 8.1.7 version that the container prints. The driver is
definitely 9i and not 8.1.7 and it's the very first thing in the
classpath.
Is this a problem with the driver really or is it a WLS issue?
Thanks,
Dejan

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

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

Table relationship between hierarchy level and merchandise category

1) Want to find Merchadise Category from Merchandise Hierarchy level which is attached with same Merchandise category.
I am having data/TABLE as below.
my input: M_WWG1C_class
i want to fetch data matkl in T023 or matkl in MARA for the same article within same merchandise category.
How i can have link?
2) i am having input CAWN_atwrt(Characteristic Value) and how i can reach matkl in T023 or matkl in MARA for the same article within same merchandise category.

Oracle does not support REPEATABLE READ transaction isolation level. It only supports SERIALIZABLE, READ COMMITED and READ ONLY isolation levels.
The default is READ COMMITED.
While the READ COMMITED can access all the committed data till the point of execution in transaction, READ SERIALIZABLE can access committed data till the point of start of transaction.
Another difference between two with respect to ROW LEVEL LOCKING is
Both read committed and serializable transactions use row-level locking, and both will wait if they try to change a row updated by an uncommitted concurrent transaction. The second transaction that tries to update a given row waits for the other transaction to commit or roll back and release its lock. If that other transaction rolls back, the waiting transaction, regardless of its isolation mode, can proceed to change the previously locked row as if the other transaction had not existed.
However, if the other blocking transaction commits and releases its locks, a read committed transaction proceeds with its intended update. A serializable transaction, however, fails with the error "Cannot serialize access", because the other transaction has committed a change that was made since the serializable transaction began.
Read following for clearing your concepts on transaction isolation levels and locking mechanisms
http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/server.920/a96524/c21cnsis.htm#2414
Chandar

Isolation level: repeatable read vs read stability.

I was going through the following link [http://www.developer.com/print.php/3706251] about database isolation levels. There was a statement:
In Read Stability, only rows that are retrieved or modified are locked, whereas in Repeatable Read, all rows that are being referenced are locked.
What is meant by "all rows that are being referenced".
According to my understanding in case of repeatable read, the table is locked. Is this understanding correct?
Edited by: user476453 on Oct 29, 2010 2:03 AM

This article is referencing DB2 isolation levels and not Oracle ones: isolation levels are standardized in SQL but practically they can be very different from one database to another. For Oracle please refer to http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/consist.htm#CNCPT621.
Your DB2 question should be posted on DB2 forum and not on an Oracle forum.

EJB Isolation levels in ejb-j2ee-engine.xml

Can anyone explain to me why I only seem to have the option of using the 'repeatable read' isolation level in Netweaver Developer Studio?
I'm new to SAP and Netweaver but as a seasoned J2EE developer I would have expected to find read committed, read uncommitted, serializable, as well as repeatable read.
Is there some SAP or Netweaver specific reason why I don't get to choose these options, or do I need to enable them by configuring properties somewhere?

Hi Steve,
The reason is that the J2EE Engine EJB Container supports Read Committed and Repeatable Read isolation levels and Read Committed is the default one. That's why you only have the option of specifying Repeatable Read.
For more information on locking and isolation levels please have a look at these documents:
http://help.sap.com/saphelp_nw04/helpdata/en/37/019b3e25f95f14e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/a1/d81db94a10bc4b83b3f60b0e3037e7/frameset.htm
Best regards,
Vladimir

Query Connection Isolation Levels

I can do SA_CONN_LOCKS and get the information of all the connections. I have all the connection numbers.
I then need a way to determine the ISOLATION LEVEL of each of the connections. We use a different ISOLATION LEVEL and we want to make sure that isolation level is proper for all connections to stop freezing.
I'm sure I can get the isolation level of the current connection (ITSELF) ---
1. How do I get the isolation level of my own connection?
2. How do I get the isolation levels of all the other connections? (If I have to do it manually for each connection, that's not an issue for me)
Please help!
We are setting an EXECLUSIVE lock on a table which is causing all the other workstations to freeze, and I'm sure that we are setting the isolation level to stop this from happening when opening all the connections - so for some reason, something is getting set back or the user is creating other custom connections and locking records.
Thank you.
Sybase SQL Anywhere 12.01

Hi Robert,
I have logged the incident with support. We haven't move much towards resolution on that side, but we have on our side.
If you're ever finding that an incident needs more attention to it or that you are not receiving an urgent reply from SAP, there is a mechanism to have the SAP Customer Interaction Center involved and for the incident to be flagged at higher support levels, if the production situation warrants it - see: https://websmp106.sap-ag.de/call1sap
The query runs just fine! It runs in 3 seconds.
If we put those two lines back - the query freezes and can sit there forever.
On the surface, this doesn't sound like a locking issue, but more of a performance issue with those views/tables. Especially if you are using isolation level 0.
They asked us to do logging (your SAP SUPPORT) and we did ..... we gave it to them and they came back and told us it could have to do with some known bug called "Issue with parallelism and we can test this by setting the max_query_tasks to 1"
Yes, after reviewing the incident I can see that we have requested and you have performed and provided us with some request logging, and after reviewing this information we had found that there were large table scans inside queries with intra-query parallelism involved (indicating a performance issue). To diagnose the performance issue further, we have requested graphical plans with statistics from these queries to see in more detail about why we are picking the query plans we are at that time. The optimizer uses statistical analysis to pick plans so therefore we need to understand the statistics behind its decisions.
The above suggestion was provided as an interim diagnostic test in order to determine if the behaviour is related to known fixed issues related to intra-query parallelism on earlier builds of 12.0.1. Providing the specific build number of 12.0.1 would avoid needing to run the diagnostic test.
However, if you are convinced that locking is truly the root issue of your problem, please provide the full output of sa_locks() at this time - there should be 11 columns, including the 'lock_type' information which would provide the type of object that is being locked:
conn_name,conn_id,user_id,table_type,creator,table_name,index_id,lock_class,lock_duration,lock_type,row_identifier
If you are over 1000 locks, you will need to increase the 'max_locks' argument to sa_locks().
I have also noted that you have also just provided a response to us in the incident shortly after posting here. Please continue to use the support incident to work with us directly for the diagnostic discussion and your resolution options.
Regards,
Jeff Albion
SAP Active Global Support

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.

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

Isolation level and optimist/pessimist locking

Similar Messages

Maybe you are looking for