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.

Similar Messages

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

  • Clarification on Transaction Isolation Levels

    Hi,
         I have a query regarding the cache behaviour for CONCUR_OPTIMISTIC->TRANSACTION_COMMITTED isolation level.
         For CONCUR_OPTIMISTIC->TRANSACTION_REPEATABLE_GET, the TransactionMap javadoc states -> "get" operations move the retrieved values into the local map.
         How does the get operation behaviour differ in case of CONCUR_OPTIMISTIC->TRANSACTION_COMMITTED isolation level? Is the value put into the local map on a get operation? If not, is there a possibility of near cache data getting corrupted if the user makes changes on the object returned by the near cache and abends the transaction before calling the persist on that object?
         Thanks,
         Abhay

    Gene,
         So as to understand this behavior a bit more, what happens when the user calls the "get" operation with the CONCUR_OPTIMISTIC->TRANSACTION_COMMITTED settings, make changes to this object returned by near cache and does not call the put or remove operation on the cache for some reason. Will the changes be seen by "get" operations in other transactions?
         In essence, does the "get" operation give the reference to the actual object in the near cache when the isolation settings are CONCUR_OPTIMISTIC->TRANSACTION_COMMITTED?
         We are experiencing the near cache in one of the members in the cache cluster getting out of synch with the data in other cluster members.
         Thanks,
         Abhay

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

  • Question Isolation level on performance

    If I have a question for report, and this report is not really realtime necessary(for example, munites delay is fine). in order to improve performance for report, allow query to get dirty data even there is a transaction lock on on table. So if change isolation level from 3 to 1 or 0, any big performace gain?

    Not sure what the functionality of the report is but you may also look at using the "readpast" query hint which allows skipping rows which on which incompatible locks are being held.
    Dirty read should be carefully evaluated/explained with the users of report since sometimes they will approve dirty read for performance benefit but won't really understand the implication. Just from my book of experience.
    warm regards,
    sudhir

  • Isolation level in cftransaction

    Hi all,
    We have been using cftransaction on our transaction process page where we need to do multiple insert queries to save transaction data.  If there is no error, we commit the transaction.  Once in a while though, we get the error message "Transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."  We are on SQL Server 2005.
    What I understand from that error message is that there are multiple transactions trying to access the same tables at the same time.  Implicitly, one transaction has locked the tables while it is inserting data, and other transactions are not able to access them.
    Now I don't fully understand cftransaction beyond its commit / rollback functionality.  I never quite understood the isolationLevel attribute of cftransaction.  I have read a number of descriptions, but the terms dirty read, phantom data, nonrepeatable reads are still confusing to me.  What I do understand is that unless we specify isolationLevel = serializable in a transaction, it is not locking the tables it is accessing.  In our use of cftransaction, we don't specify the isolationLevel attribute ( I believe the default is read committed .)
    So here are my questions:
    1.  If we don't specify any isolation level, why are we getting deadlock transactions?
    2.  If we do want to lock the tables using isolationLevel = serializable, does a concurrent transaction trying to use the same tables automatically get deadlocked?  Or is there a mechanism to specify timeout ala cflock timeout attribute?
    I'd appreciate someone clearing up my understanding of cftransaction.  Thanks!

    I know this is an old post, but I have had the same questions recently and based on my recent findings, have attempted to answer your questions below for anyone in the future:
    1.  If we don't specify any isolation level, why are we getting deadlock transactions?
    The reason this could be happening is because the cftransaction tag will use the default isolation level of your database. For SQL Server this is usually Read Committed. However, it is important to note that, "Choosing a transaction isolation level does not affect the locks acquired to protect data modifications. A transaction always gets an exclusive lock on any data it modifies, and holds that lock until the transaction completes, regardless of the isolation level set for that transaction. For read operations, transaction isolation levels primarily define the level of protection from the effects of modifications made by other transactions." This quote is taken directly from the MS SQL Server site. I understand this by stating that if you are doing a read, the isolation level determines the quality and/or quantity of the data returned from the read. If you are doing data modifications, the transaction will always get an exclusive lock on any data being modified. The cftransaction tag can control when it is committed based on its placement, but does not control the data modification isolation levels.
    2.  If we do want to lock the tables using isolationLevel = serializable, does a concurrent transaction trying to use the same tables automatically get deadlocked?  Or is there a mechanism to specify timeout ala cflock timeout attribute?
    The first question helps to answer this second one. The isolation level attribute (serializable or other) applies to the level of protection read operations will receive from other transactions' modifications. It does not effect on the locks aquired to protect data modifications. This is controlled by the database itself. The cflock tag only applies to CF meaning it ensures single thread access to that code (e.g. application, session or server variables), not to the database.
    I hope this helps someone in the future and that I have not misstated anything. If anyone can provide better clarification please do so.

  • Is isolation level setting(Dirtry Read Options) working fine for DB2?

    Hello Gurus,
    We are building obiee reports on DB2 OLTP database. As per my understanding if we select the Isolation level as "Dirty Read" it should not lock the tables but. In our case it is locking the tables and causing others(application Users) not to update the data. Please let us know if you have faced the same issue or any solution. Our production migration is stopped because of this issue.
    Thanks,
    Anil

              Just a follow up, I think the isolation level is perhaps being set to REPEATABLE_READ,
              since that is what seems to be happening. The value from the first read is maintained
              through subsequent reads in the same transaction.
              lance
              "Lance" <[email protected]> wrote:
              >
              >I have a Message Driven Bean (MDB) that is container managed, and its
              >transaction
              >isolation is set to TRANSACTION_READ_COMMITTED in weblogic-ejb-jar.xml
              >and that
              >seems to work fine. If I look at an entity bean in onMessage which is
              >updated/commited
              >outside the transaction I can see the updates no problem.
              >
              >Now the problem is this.. inside the onMessage method, the MDB creates
              >a new
              >instance of a class. This class starts up its own UserTransaction (using
              >(UserTransaction)new
              >InitialContext().lookup("javax.transaction.UserTransaction")) and goes
              >into a
              >loop working away. Inside the loop it is inspecting a value on an entity
              >bean.
              > The classs never sees any updates to this bean which are made outside
              >this new
              >UserTransaction.
              >
              >It looks to me that the UserTransaction that the class is getting has
              >a different
              >isolation level (serialized?). Is there a way to set the isolation level
              >for
              >a UserTransaction?
              >
              >Any help would be great!
              >
              >lance
              

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

  • Isolation level configuration

    Hello there,
    I am converting our not-transaction based application to use transactions. As I want to reduce the performance impact I am configuring some transactions to some lesser isolation levels. As far as I understand from the docs, the general way to do it is to set proper isolation level in TransactionConfig when creating a transaction.
    But from what I see in the docs, it's possible to use PrimaryIndex.get() third parameter (lockMode) to specify isolation for the specific operation as well.
    So my question is: what are props and cons of per-operation isolation configuration compared to per-transaction isolation configuration?
    I.e. I'm considering which approach is better:
    1.
    TransactionConfig txnConfig = new TransactionConfig();
    txnConfig.setReadUncommitted(true);
    Transaction txn = myEnv.beginTransaction(null, txnConfig);
    for (id : idList)
    primaryIndex.get(txn, id, null);
    2.
    Transaction txn = myEnv.beginTransaction(null, null);
    for (id : idList)
    primaryIndex.get(txn, id, LockMode.READ_UNCOMMITTED);
    In general I understand that specifying isolation on per-operation basis probably was intended to be used as a tool for locally changing the general transaction setting like
    3.
    TransactionConfig txnConfig = new TransactionConfig();
    txnConfig.setReadUncommitted(true);
    Transaction txn = myEnv.beginTransaction(null, txnConfig);
    for (id : idList)
    primaryIndex.get(txn, id, id == 5? LockMode.READ_COMMITTED : null);
    but I want to know if the 2nd approach is legal and would not lead to some bad consequences.

    Hello Linda,
    Thanks for clarification!
    Still your last note makes me think that I'm doing something that I should not. When you say :
    it does seem unusual to have a transaction where you always choose to use READ_UNCOMMITTEDdo you mean that I don't have to use a transaction for a read-only operations sequence?
    Here's my use-case. In my application I have 2 types of threads:
    Threads of the 1st type would just update some record in the DB. I do it like this:
    Transaction txn = myEnv.beginTransaction(null, null);
    Record record = primaryIndex.get(txn, id, LockMode.RMW);
    record.update(...);
    primaryIndex.putNoReturn(txn, record);
    txn.commit();
    I'm using LockMode.RMW to prevent other threads from writing this record without reading it first.
    Threads of the 2nd type would perform reading of some set of records. I do it like this:
    Transaction txn = myEnv.beginTransaction(null, null);
    int result = 0;
    for (id : idList)
    Record record = primaryIndex.get(txn, id, LockMode.READ_UNCOMMITTED);
    result += record.getValue();
    txn.commit();
    or
    Transaction txn = myEnv.beginTransaction(null, null);
    int result = 0;
    EntityCursor<Record> cursor = primaryIndex.entities(txn, CursorConfig.READ_UNCOMMITTED);
    for (Record record : cursor)
    result += record.getValue();
    cursor.close()
    txn.commit();
    I am using READ_UNCOMMITTED there to reduce chances of locking, as I'm not really interested whether I get the value before it gets updated by some 1st type transaction or after.
    Can you give me any advice on how I should do it in more correct way?
    Should I just remove the transaction from the 2nd type of threads (so there would be no questions on what does the txn.commit() commits there)?
    Does the fact that I'm using LockMode.READ_UNCOMMITTED means that I can get the record in some internally-inconsistent state?

  • Isolation Level vs. Locking

    Hello,
    I am still wrestlling a bit with the issues involved in setting an isolation
    level. I am using WL 5.1, Oracle, and CMP.
    I do now understand the issues involved between Oracle's
    SERIALIZABLE and READ-COMMITTED isolation levels, etc.
    But I also note that weblogic uses a pessimistic locking
    approach for serializing access to entity ejb's. Doesn't this
    locking supercede anything but an isolation level of
    SERIALIZABLE? What happens with an isolation level
    of READ-COMMITTED, even though the access to an
    entity within any transaction will be serialized anyway?
    Are there issues related to persistence issues outside of
    ejb's, such as using JMS persistent messages within the
    same system (same connection pool, etc.).
    Also, I note that the ejb 2.0 spec in weblogic will allow
    a more optimistic locking model. In this case, how will
    multiple commits behave, will they behave according
    to the isolation level chosen (READ-COMMITTED
    or SERIALIZABLE?).
    It's all confusing. What is the point, in ejb 1.1, for allowing
    the bean developer to specify an isolation level, if all
    access to entities will be done with exclusive locks?
    What happens with multiple result finder methods? Does
    this place exclusive locks on each entity found, within
    a transaction?
    Should I spend more time worrying about locking
    models or isolation levels.
    Am I just going around in circles?
    Jason
    Jason Rosenberg
    SquareTrade
    (remove 'nospam' from my return address)

    Well, for now, I am designing for Oracle. What do you mean
    by hazy?
    Kirk Wylie <[email protected]> wrote in message news:[email protected]...
    Probably not something you can count on guaranteeing no blocking. The
    database could very well block here, particularly if your'e using
    anything other than Oracle on the back-end, and Oracle can be a bit,
    ahem, hazy in its acceptance of its own semantics here.
    Kirk Wylie
    Jason Rosenberg wrote:
    Well, if the database table is set up to use READ-COMMITTED,
    then it shouldn't block on the database, correct?
    Jason
    Cameron Purdy <[email protected]> wrote in message news:[email protected]...
    ... which means it could block on the database, correct?
    Cameron Purdy
    "Rob Woollen" <[email protected]> wrote in message
    news:[email protected]...
    A finder will never block on a container lock. For instance, imagine
    that primary keys 3 and 4 are currently participating in a transaction
    and are locked in server A. If a finder is called in server A which
    returns these keys, the finder will run independently of the EJB server
    locks. (Of course the database isolation will still apply.)
    -- Rob
    Jason Rosenberg wrote:
    Ah, clustering saves the day!
    I'm wondering though, since we don't have control over which
    server in a cluster a given ejb may run on at any given time,
    the concurrent behavior may be different to control. Some
    times you can have concurrent access based on
    READ-COMMITTED on the db level, and some times weblogic
    will force a SERIALIZABLE behavior if 2 conflicting
    ejb's get instantiated in the same container.
    This is what I want. I would like complex finder methods
    to be able to return a collection of primary keys over a
    table, based on a READ-COMMITTED basis. This
    needs to happen often, and shouldn't block (it's ok
    if it misses out on uncommitted data in process, or
    if it returns keys that may be in the process of being
    deleted). But I don't ever want it to block because
    another component has uncomitted changes in process.
    Ideas? Wait for ejb2.0?
    Jason
    Rob Woollen <[email protected]> wrote in message
    news:[email protected]...
    It matters if you are in a cluster, or if othercomponents/applications
    are accessing the same data.
    It will also matter if your db does not have row-level locking.
    -- Rob
    Jason Rosenberg wrote:
    I've excerpted below some of the text from the weblogic
    documentation.
    What this says to me is that, indeed, if an ejb entity is in anywayinvolved
    in a transaction, all other transactions will be blocked frominstantiating
    and using the bean instance until the transaction is over.
    This is a de-facto SERIALIZABLE isolation level, is it not, with allthe
    plusses and minuses. The plus is that data integrity is maintained,the
    minus is that concurrent access is negatively effected.
    What am I missing. Given this mechanism, what difference does it
    make whether I use of a transaction isolation level ofREAD-COMMITTED
    or SERIALIZABLE?
    It looks like the story does change for ejb2.0.....
    From the weblogic online documentation at:
    http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#108796
    7
    Locking Model for Entity EJBs
    The EJB 1.1 container in WebLogic Server Version 5.1 uses apessimistic locking mechanism for entity EJB instances. As clients
    enlist an EJB or EJB method in a transaction, WebLogic Server placesan exclusive lock on the EJB instance or method for the
    duration of the transaction. Other clients requesting the same EJBor method block until the current transaction completes.
    This method of locking provides reliable access to EJB data, andavoids unnecessary calls to ejbLoad() to refresh the EJB
    instance's
    persistent fields. However, in certain circumstances pessimistic
    locking may not provide the best model for concurrent access to
    the
    EJB's data. Once a client has locked an EJB instance, other clients
    are blocked from the EJB's data even if they intend only to
    read
    the persistent fields.
    To improve concurrent access for entity EJB's, the WebLogic Server
    EJB 2.0 container enables you to defer locking services to
    the
    underlying database. In most cases, the underlying data store can
    provide finer granularity for locking EJB data, and improve
    throughput for concurrent access to the bean's data. See EJB 2.0 forBEA WebLogic Server Overview for more information.
    Cameron Purdy <[email protected]> wrote in message
    news:[email protected]...
    I believe the "locking" refers to an internal WL implementationthat
    prevents multiple threads from accessing an EJB instance.
    Cameron Purdy, LiveWater
    "Jason Rosenberg" <[email protected]> wrote in message
    news:[email protected]...
    Hello,
    I am still wrestlling a bit with the issues involved in setting
    an
    isolation
    level. I am using WL 5.1, Oracle, and CMP.
    I do now understand the issues involved between Oracle's
    SERIALIZABLE and READ-COMMITTED isolation levels, etc.
    But I also note that weblogic uses a pessimistic locking
    approach for serializing access to entity ejb's. Doesn't this
    locking supercede anything but an isolation level of
    SERIALIZABLE? What happens with an isolation level
    of READ-COMMITTED, even though the access to an
    entity within any transaction will be serialized anyway?
    Are there issues related to persistence issues outside of
    ejb's, such as using JMS persistent messages within the
    same system (same connection pool, etc.).
    Also, I note that the ejb 2.0 spec in weblogic will allow
    a more optimistic locking model. In this case, how will
    multiple commits behave, will they behave according
    to the isolation level chosen (READ-COMMITTED
    or SERIALIZABLE?).
    It's all confusing. What is the point, in ejb 1.1, for allowing
    the bean developer to specify an isolation level, if all
    access to entities will be done with exclusive locks?
    What happens with multiple result finder methods? Does
    this place exclusive locks on each entity found, within
    a transaction?
    Should I spend more time worrying about locking
    models or isolation levels.
    Am I just going around in circles?
    Jason
    Jason Rosenberg
    SquareTrade
    (remove 'nospam' from my return address)
    Kirk Wylie | mailto:[email protected] | http://www.radik.com

  • Isolation Level of SQL Server when committing statements

    Dear All,
    Can someone please tell me whether Read Committed and
    Auto commit means the same thing in transaction Isolation level?
    I assume if SQL default is Auto Commit then it commits all transactions whether we use
    "Commit Transaction' cmd or not.
    Thank-you
    SQL75

    We write  T-SQL in both right?
    Sorry didnt understand what you meant by that.
    Isolation Level and Transaction Management are two different aspects of T-SQL.
    The former talks about level up to which a transaction can proceed without intervention from other parallel
    transactions. In Read Commited no other transaction will be able to read data that is in use by the current transaction unless its done ie commited/rolled back. But it may introduce additional data that may fall in the range of data which first transaction
    is currently in hold causing phantom reads
    The transaction management explains whether one needs to explicitly specify start and end of transaction
    or whether system will implicitly dtermine the start and end of the transaction.
    Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

  • Isolation Level of iViews

    Hi,
    I have an iView, on an EP5 SP6, that currently has Isolation Level 4 enabled. I would like it to go to Isolation Level 3 since the size of the iView changes each day.
    The iView is inherited from a KM iView and I have been told that KM iViews need to run with Isolation Level 4. Is this really correct?
    Thanks in advance.
    Cheers
    Kris Kegel

    We write  T-SQL in both right?
    Sorry didnt understand what you meant by that.
    Isolation Level and Transaction Management are two different aspects of T-SQL.
    The former talks about level up to which a transaction can proceed without intervention from other parallel
    transactions. In Read Commited no other transaction will be able to read data that is in use by the current transaction unless its done ie commited/rolled back. But it may introduce additional data that may fall in the range of data which first transaction
    is currently in hold causing phantom reads
    The transaction management explains whether one needs to explicitly specify start and end of transaction
    or whether system will implicitly dtermine the start and end of the transaction.
    Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

  • SQLServer Isolation Level Problem?

    Since the MSSQLServer driver has trouble when returning explicit cursors, and since the complexitites of one of our procedures requires the use of cursors we have been forced to split a DBMS procedure into two. Ie. we have one method that updates the database and one that retrieves the "return value", ie. a setXXX and then a getXXX method.
    The problem is that we sometimes get an empty resultset from the getXXX method. Note that this behaviour is not due to the server code as this error is not present if run directly on the SQLServer (ie, not through the JDBC driver). Now testing to and fro suggests that the error is caused by some sort of parallell behaviour or isolation level trouble in the driver, but what exactly? The thing is, if I insert a pause of a few milliseconds between the two calls it works correctly (of course I cannot place a "random" pause there in production code since the pause will probably vary depending on the underlying hardware). I have tried setting to different TransactionIsolation levels, but get the same result all the time. There is only one linear execution of the code as shown below (no multithreading in the java application).
    What I'm wondering is: are there any "switches" to turn in relation to waiting for a a stored procedure to finish execution before the next is called? I would expect this to be implicit, but perhaps the SQLServer runs them in parallell and therefore the second method is called before the first is finished, but then, shouldn't the TransactionIsolationLevel of Serializable hinder this? I would appreciate any help on this one, sample code below, the problem being that wereas the while loop should always print the line it sometimes doesn't since the result is empty (not null, empty). It isn't the parameter to the execute_task either, we get the "missing result" problem with different paramaters that all always work when run directly on the SQLServer (via SQL Query Analyzer).
    //Execute the update to the server
    CallableStatement execute_task = connection.prepareCall("{call setXXX(?)}");
    execute_task.setInt(1, 1);
    execute_task.execute();
    //Retrieve the task execution results:
    CallableStatement show_execute_task = connection.prepareCall("{call getXXX}");
    show_execute_task.execute();
    ResultSet show_execute_resultset = show_execute_task.getResultSet();
    while(show_execute_resultset.next()){
    System.out.println("Result received");
    }

    Since the MSSQLServer driver has trouble when
    returning explicit cursors, and since the
    complexitites of one of our procedures requires the
    use of cursors we have been forced to split a DBMS
    procedure into two. Ie. we have one method that
    updates the database and one that retrieves the
    "return value", ie. a setXXX and then a getXXX method.
    The problem is that we sometimes get an empty
    resultset from the getXXX method. Note that this
    behaviour is not due to the server code as this error
    is not present if run directly on the SQLServer (ie,
    not through the JDBC driver). Now testing to and fro
    suggests that the error is caused by some sort of
    parallell behaviour or isolation level trouble in the
    driver, but what exactly? The thing is, if I insert a
    pause of a few milliseconds between the two calls it
    works correctly (of course I cannot place a "random"
    pause there in production code since the pause will
    probably vary depending on the underlying hardware).
    I have tried setting to different
    TransactionIsolation levels, but get the same result
    all the time. There is only one linear execution of
    the code as shown below (no multithreading in the
    java application).
    What I'm wondering is: are there any "switches" to
    turn in relation to waiting for a a stored procedure
    to finish execution before the next is called? I would
    expect this to be implicit, but perhaps the SQLServer
    runs them in parallell and therefore the second methodthis is what i would expect. parallel execution i mean... othewise you might as well use Access...
    is called before the first is finished, but then,
    shouldn't the TransactionIsolationLevel of
    Serializable hinder this? I would appreciate any helpi'm not sure...
    t be perfectly honest while i understand the different transaction levels on their face level as described in java.sql.Connection I am not entirely sure WHAT the expected behaviour actually is for each level.
    not to get too OT here but for example TRANSACTION_REPEATABLE_READ
    if the first transaction reads row 1 from tableA
    then a second transaction changes row 1 in table A and commits the changes
    the first transaction reads row 1 from table A again... what the heck is supposed to happen. i think it is supposed to read the same values as the first pass even though commited changes have been made but i'm not entirely sure.
    on this one, sample code below, the problem being that
    wereas the while loop should always print the line it
    sometimes doesn't since the result is empty (not null,
    empty). It isn't the parameter to the execute_task
    either, we get the "missing result" problem with
    different paramaters that all always work when run
    directly on the SQLServer (via SQL Query Analyzer).
    //Execute the update to the server
    CallableStatement execute_task =
    connection.prepareCall("{call setXXX(?)}");
    execute_task.setInt(1, 1);
    execute_task.execute();
    //Retrieve the task execution results:
    CallableStatement show_execute_task =
    connection.prepareCall("{call getXXX}");
    show_execute_task.execute();
    ResultSet show_execute_resultset =
    show_execute_task.getResultSet();
    while(show_execute_resultset.next()){
    System.out.println("Result received");
    }i don't really follow your code too well here but here is what i would suggest...
    fetch whatever the first procedure returns FIRST.
    this should force your app to wait on this before you execute the second one.
    does that make sense? it seems simple to me but maybe i'm missing something.

  • 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

  • Problems in using isolation level serializable

    Dear everyone:
    This is the problem I met while using isolation level
    serializable in ORALCE 8.0.3 for Netware:
    Program 1 Program2
    Insert record 1 into table 1
    select record 1 from table1
    commit
    select record1 from table1
    insert record 2 into table1
    select record2 from table1
    commit
    select record2 from table1
    update record2 from table1
    commit
    delete record2 from table1
    commit
    update record1 from table1
    *ORA-8177 cannot serialize
    access for this transaction
    According to my understanding to the serialization isolation
    level, it should not occurs.
    Anyone can give me some ideas?
    Regards!
    null

    Dear everyone:
    This is the problem I met while using isolation level
    serializable in ORALCE 8.0.3 for Netware:
    Program 1 Program2
    Insert record 1 into table 1
    select record 1 from table1
    commit
    select record1 from table1
    insert record 2 into table1
    select record2 from table1
    commit
    select record2 from table1
    update record2 from table1
    commit
    delete record2 from table1
    commit
    update record1 from table1
    *ORA-8177 cannot serialize
    access for this transaction
    According to my understanding to the serialization isolation
    level, it should not occurs.
    Anyone can give me some ideas?
    Regards!
    null

Maybe you are looking for