Setting isolation level fails

Hi,
Im using Kodo 3.0.0 on Oracle 8.1.7.
I tried to define the isolation level in the kodo.properties:
e.g.: kodo.jdbc.TransactionIsolation: serializable
Unfortunately Oracle throws an exception which says, that "set
transaction" has to be the first statement called within a transaction. I
get this exception on almost every db access.
java.sql.SQLException: ORA-01453: SET TRANSACTION muss erste Anweisung der
Transaktion sein
at
kodo.jdbc.sql.SQLExceptions.getFatalDataStore(SQLExceptions.java:42)
at
kodo.jdbc.sql.SQLExceptions.getFatalDataStore(SQLExceptions.java:24)
at
kodo.jdbc.schema.LazySchemaFactory.findTable(LazySchemaFactory.java:1
50)
at
kodo.jdbc.meta.VerticalClassMapping.fromMappingInfo(VerticalClassMapp
ing.java:135)
at
kodo.jdbc.meta.RuntimeMappingProvider.getMapping(RuntimeMappingProvid
er.java:56)
at
kodo.jdbc.meta.MappingRepository.getMappingInternal(MappingRepository
java:342)
at
kodo.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:29
7)
at
kodo.jdbc.meta.MappingRepository.getMappingInternal(MappingRepository
java:325)
at
kodo.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:29
7)
at
kodo.jdbc.meta.MappingRepository.getMappings(MappingRepository.java:2
72)
at
kodo.jdbc.meta.MappingRepository.getMetaDatas(MappingRepository.java:
256)
at kodo.query.AbstractQuery.internalCompile(AbstractQuery.java:538)
at kodo.query.AbstractQuery.compile(AbstractQuery.java:502)
at kodo.datacache.CacheAwareQuery.compile(CacheAwareQuery.java:265)
-- Wolfgang

Marc,
Here you go...
kodo.util.FatalDataStoreException: ORA-01453: SET TRANSACTION must be
first statement of transaction
     at
kodo.runtime.PersistenceManagerImpl.beforeCompletion(PersistenceManagerImpl.java:897)
     at kodo.runtime.LocalManagedRuntime.commit(LocalManagedRuntime.java:69)
     at
kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:566)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.initTestModel(AbstractConcurrentAction.java:290)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction$InitRunnable.run(AbstractConcurrentAction.java:212)
     at
edu.sjsu.recon.util.ConcurrencyUtilities.executeSynchronized(ConcurrencyUtilities.java:20)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.setup(AbstractConcurrentAction.java:75)
     at
edu.sjsu.recon.execution.ServerExecutor.beforeExecute(ServerExecutor.java:27)
     at
edu.sjsu.recon.execution.AbstractExecutor.execute(AbstractExecutor.java:43)
     at
edu.sjsu.recon.execution.DefaultExecutionCoordinator.executeAction(DefaultExecutionCoordinator.java:25)
     at
edu.sjsu.recon.server.handler.ExecutionRequestHandler.handleRequest(ExecutionRequestHandler.java:63)
     at edu.sjsu.recon.server.RequestProcessor.run(RequestProcessor.java:90)
NestedThrowablesStackTrace:
kodo.util.DataStoreException: ORA-01453: SET TRANSACTION must be first
statement of transaction
     at
kodo.jdbc.sql.DBDictionary.newDataStoreException(DBDictionary.java:3004)
     at kodo.jdbc.sql.SQLExceptions.getDataStore(SQLExceptions.java:77)
     at kodo.jdbc.sql.SQLExceptions.getDataStore(SQLExceptions.java:63)
     at kodo.jdbc.sql.SQLExceptions.getDataStore(SQLExceptions.java:43)
     at kodo.jdbc.runtime.JDBCStoreManager.connect(JDBCStoreManager.java:871)
     at
kodo.jdbc.runtime.JDBCStoreManager.retainConnection(JDBCStoreManager.java:189)
     at kodo.jdbc.runtime.JDBCStoreManager.begin(JDBCStoreManager.java:114)
     at
kodo.runtime.DelegatingStoreManager.begin(DelegatingStoreManager.java:95)
     at
kodo.runtime.PersistenceManagerImpl.flushInternal(PersistenceManagerImpl.java:1004)
     at
kodo.runtime.PersistenceManagerImpl.beforeCompletion(PersistenceManagerImpl.java:885)
     at kodo.runtime.LocalManagedRuntime.commit(LocalManagedRuntime.java:69)
     at
kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:566)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.initTestModel(AbstractConcurrentAction.java:290)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction$InitRunnable.run(AbstractConcurrentAction.java:212)
     at
edu.sjsu.recon.util.ConcurrencyUtilities.executeSynchronized(ConcurrencyUtilities.java:20)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.setup(AbstractConcurrentAction.java:75)
     at
edu.sjsu.recon.execution.ServerExecutor.beforeExecute(ServerExecutor.java:27)
     at
edu.sjsu.recon.execution.AbstractExecutor.execute(AbstractExecutor.java:43)
     at
edu.sjsu.recon.execution.DefaultExecutionCoordinator.executeAction(DefaultExecutionCoordinator.java:25)
     at
edu.sjsu.recon.server.handler.ExecutionRequestHandler.handleRequest(ExecutionRequestHandler.java:63)
     at edu.sjsu.recon.server.RequestProcessor.run(RequestProcessor.java:90)
NestedThrowablesStackTrace:
java.sql.SQLException: ORA-01453: SET TRANSACTION must be first statement
of transaction
     at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:125)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:305)
     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:272)
     at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:623)
     at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:112)
     at oracle.jdbc.driver.T4CStatement.execute_for_rows(T4CStatement.java:474)
     at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1028)
     at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1516)
     at
oracle.jdbc.driver.PhysicalConnection.setTransactionIsolation(PhysicalConnection.java:1412)
     at
com.solarmetric.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:266)
     at
com.solarmetric.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:266)
     at
com.solarmetric.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:266)
     at
com.solarmetric.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:266)
     at
com.solarmetric.jdbc.ConfiguringConnectionDecorator.decorate(ConfiguringConnectionDecorator.java:93)
     at
com.solarmetric.jdbc.DecoratingDataSource.decorate(DecoratingDataSource.java:90)
     at
com.solarmetric.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:82)
     at
com.solarmetric.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:131)
     at
kodo.jdbc.schema.DataSourceFactory$DefaultsDataSource.getConnection(DataSourceFactory.java:305)
     at
kodo.jdbc.runtime.JDBCStoreManager.connectInternal(JDBCStoreManager.java:887)
     at kodo.jdbc.runtime.JDBCStoreManager.connect(JDBCStoreManager.java:865)
     at
kodo.jdbc.runtime.JDBCStoreManager.retainConnection(JDBCStoreManager.java:189)
     at kodo.jdbc.runtime.JDBCStoreManager.begin(JDBCStoreManager.java:114)
     at
kodo.runtime.DelegatingStoreManager.begin(DelegatingStoreManager.java:95)
     at
kodo.runtime.PersistenceManagerImpl.flushInternal(PersistenceManagerImpl.java:1004)
     at
kodo.runtime.PersistenceManagerImpl.beforeCompletion(PersistenceManagerImpl.java:885)
     at kodo.runtime.LocalManagedRuntime.commit(LocalManagedRuntime.java:69)
     at
kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:566)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.initTestModel(AbstractConcurrentAction.java:290)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction$InitRunnable.run(AbstractConcurrentAction.java:212)
     at
edu.sjsu.recon.util.ConcurrencyUtilities.executeSynchronized(ConcurrencyUtilities.java:20)
     at
edu.sjsu.recon.contribution.action.jdo.v10.kodo.v32.oracle.v101.simple.concurrency.AbstractConcurrentAction.setup(AbstractConcurrentAction.java:75)
     at
edu.sjsu.recon.execution.ServerExecutor.beforeExecute(ServerExecutor.java:27)
     at
edu.sjsu.recon.execution.AbstractExecutor.execute(AbstractExecutor.java:43)
     at
edu.sjsu.recon.execution.DefaultExecutionCoordinator.executeAction(DefaultExecutionCoordinator.java:25)
     at
edu.sjsu.recon.server.handler.ExecutionRequestHandler.handleRequest(ExecutionRequestHandler.java:63)
     at edu.sjsu.recon.server.RequestProcessor.run(RequestProcessor.java:90)
Marc Prud'hommeaux wrote:
Cleo-
Can you post the complete stack (including all the nested stack traces)?
In article <[email protected]>, Cleo wrote:
Marc,
Here is the stack:
ORA-01453: SET TRANSACTION must be first statement of transaction
kodo.util.FatalDataStoreException
     at
kodo.runtime.PersistenceManagerImpl.beforeCompletion(PersistenceManagerImpl.java:897)
     at kodo.runtime.LocalManagedRuntime.commit(LocalManagedRuntime.java:69)
     at
kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:566)
This is the code being executed:
Transaction initTransaction = initPersistenceManager.currentTransaction();
initTransaction.begin();
initPersistenceManager.makePersistentAll(model);
initTransaction.commit(); //EXCEPTION HERE
initPersistenceManager.close();
thx
Marc Prud'hommeaux wrote:
Cleo-
Can you post the complete stack trace from the exception? I expect it is
different from the one posted previously (which was with a much earlier
version of Kodo).
In article <[email protected]>, Cleo wrote:
Has anybody figured out how to solve this?
I am having the same problem with:
KODO 3.2
Oracle JDBC Dirver 10.1.0.3
thx
PS: (I am on a deadline for the end of this week)
Stephen Kim wrote:
First I would suggest using Kodo 3.0.1. Second I would suggest trying
to use 9.0.1 drivers which work very well with 8.1.7.
Wolfgang Hutya wrote:
Hi,
Im using Kodo 3.0.0 on Oracle 8.1.7.
I tried to define the isolation level in the kodo.properties:
e.g.: kodo.jdbc.TransactionIsolation: serializable
Unfortunately Oracle throws an exception which says, that "set
transaction" has to be the first statement called within a
transaction.
I
get this exception on almost every db access.
java.sql.SQLException: ORA-01453: SET TRANSACTION muss erste
Anweisung
der
Transaktion sein
at
kodo.jdbc.sql.SQLExceptions.getFatalDataStore(SQLExceptions.java:42)
at
kodo.jdbc.sql.SQLExceptions.getFatalDataStore(SQLExceptions.java:24)
at
kodo.jdbc.schema.LazySchemaFactory.findTable(LazySchemaFactory.java:1
50)
at
kodo.jdbc.meta.VerticalClassMapping.fromMappingInfo(VerticalClassMapp
ing.java:135)
at
kodo.jdbc.meta.RuntimeMappingProvider.getMapping(RuntimeMappingProvid
er.java:56)
at
kodo.jdbc.meta.MappingRepository.getMappingInternal(MappingRepository
java:342)
at
kodo.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:29
7)
at
kodo.jdbc.meta.MappingRepository.getMappingInternal(MappingRepository
java:325)
at
kodo.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:29
7)
at
kodo.jdbc.meta.MappingRepository.getMappings(MappingRepository.java:2
72)
at
kodo.jdbc.meta.MappingRepository.getMetaDatas(MappingRepository.java:
256)
atkodo.query.AbstractQuery.internalCompile(AbstractQuery.java:538)
at kodo.query.AbstractQuery.compile(AbstractQuery.java:502)
atkodo.datacache.CacheAwareQuery.compile(CacheAwareQuery.java:265)
-- Wolfgang
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com
Marc Prud'hommeaux
SolarMetric Inc.
Marc Prud'hommeaux
SolarMetric Inc.

Similar Messages

  • C How to Set Isolation Level in the Connection String

    How to Set Isolation Level in the Connection String using the "Microsoft OLE DB Provider for DB2 Version 4.0"?
    We are trying to move from Crystal Reporting that run against a IBM DB2 database on a mainfram to SSRS reporting and we have downloaded the "Microsoft OLE DB Provider for DB2 Version 4.0" and then worked with the DB2 Administrator to create the
    Packages.  We only have access to use the "Read Uncommitted ("MSUR001") package.   We were able to connect and pull data before he removed access to the other packages, but after setting access the Connection keeps trying to use
    the 'Cursor Stability (MSCS001)" package.   How do we change the Default to the "Read Uncommitted ("MSUR001") package???   Since it is keeps defaulting to the the other package
    we can't connect to do it in the T-SQL query, it has to be set at the Connection String level.

    Hi Dannyboy1263,
    According to your description, you want to set the Transaction Isolation Level in Connection String. Right?
    In Reporting Services, the Connection String for OLE DB Connection can only contains Provider, Data Source and Initial Catalog. There's no property for setting Transaction Isolation Level in the Connection String. Based on my knowledge, we can
    only set the Transaction Isolation Level at Query level or set it by using code (C#, VB, Java...) to call the property of Connection. So unfortunately your requirement can't be achieved currently.
    Reference:
    OLE DB Connection Type (SSRS)
    Data Connections, Data Sources, and Connection Strings in Reporting Services
    If you have any question, please feel free to ask.
    Best Regards,
    Simon Hou

  • Set isolation level in EJB 2.0

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

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

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

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

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

  • Setting Isolation level of UserTransaction Object

    can we set the Isolation level of the UserTransaction in case of bean managed transaction or in case where we are handeling transaction in servlets (I am trying to do it in servlets by geting Javax.Transaction.UserTransaction through JNDI in weblogic). UserTransaction only have few methods and none of them is to set the Isolation level. so where would be the seting or its not possible which I think should not be the case
    Thanks

    Hi,
    The UserTransaction is not the right place to set the isolation level, because then it would be the same setting
    for all data sources you access in that transaction.
    Rather, you can set the isolation level in each connection you make. That way, you can choose a different setting for each one.
    Best,
    Guy
    Guy Pardon ( [email protected] )
    Atomikos Software Technology: Transactioning the Net
    http://www.atomikos.com/

  • Setting isolation level with JDriver for Oracle/XA

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

    IJ wrote:
    edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
    if using jDriver for Oracle/XA you can not set the transaction isolation level
    for a transaction and that 'Transactions use the transaction isolation level set
    on the connection or the default transaction isolation level for the database'.
    Does this mean that you shouldn't try to set it programatically (fair enough)
    or that you can't set it in the weblogic deployment descriptor either? Also anybody
    got any idea what the default is likely to be if you are using an Oracle 9iR2
    database? Is this determined by some database setting?The system should honor the setting defined in the deployment descriptor,
    however, for oracle it may not be helpful to change it. Oracle provides two
    isolation levels. The default is always READ_COMMITTED. The other
    setting is SERIALIZABLE, but this hurts performance, and is also problematic
    in the way oracle implements it. For instance, even if you set SERIALIZABLE,
    oracle will not lock read data. It will allow other transactions to read and/or
    alter data trhat another ongoing SERIALIZABLE transaction has read. The
    only way to really lock read data in oracle is to issue oracle-specific SQL in
    your select: "SELECT ..... FOR UPDATE".
    All in all, you should collect a strong case for why you can't proceed with
    READ_COMMITTED first. Then you should research oracle's recommendations
    (and their problem record) with SERIALIZABLE.
    Joe Weinstein at BEA

  • Setting Isolation Level In A UserTransaction

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

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

  • BMT - Setting Isolation Level

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

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

  • How to set isolation level in EJB?

              How to set the isolation level(Container Manager or Bean Manager) in EJB. Thanks
              

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

  • MS SQL -- Setting isolation level

    This is driving me nuts.... we're converting from Informix to
    MS SQL 2005 ; on our Informix JDBC connections we set the isolation
    level using IFX_ISOLATION_LEVEL=x but how do we do this on
    connectors to MSSQL 2005 ?
    Our servers are Linux based, pure JDBC
    connectivity....

    This link might help:
    ColdFusion MX 6.1 and 7: Creating a data source with
    isolation level READ_UNCOMMITTED
    http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=5444c687
    HTH

  • Restore default isolation level fails with connection in pool

    Hi,
    I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
    The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
    It has to be possible to change the isolation level for transaction, isn´t it?
    Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
                    ConnectionManager connectionManager = new ConnectionManager();
              Connection con = null;
              int transactionIsolationLevel = 0;
              Queue queue = null;
              List list = null;
              try {
                   con = connectionManager.getConnection();
                   transactionIsolationLevel = con.getTransactionIsolation();
                   if( logger.isInfoEnabled())
                        logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
                   // auskommentiert für RE
                   con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
                   con.setAutoCommit( false );
              QueueManager queueManager = new QueueManager();
              list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
              con.commit();
              } catch (ClassNotFoundException cnfe) {
                   logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
                   handleExceptions(queue, cnfe);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } catch (SQLException sqle) {
                   logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
                   handleExceptions(queue, sqle);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } catch (QueueManagerException qme) {
                   logger.error(LOGLOC + "Exception executing queue manager!", qme);
                   handleExceptions(queue, qme);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } finally {
                   try {
                        con.setAutoCommit(true);
                        if( logger.isInfoEnabled())
                             logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
                        // Auskommentiert für RE
                        con.setTransactionIsolation( transactionIsolationLevel );
                        con.close();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);               
    The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
    In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
    Any hints, solutions?

    Hi,
    I am developing an application that needs to set the TransactionIsolation to SERIALIZE for a transaction. Setting the TransactionIsolation is not the problem. After this transaction is committed or rolled back, i set the isolation level back to the default i saved before.
    The code gets executed and throws no exception. The connection i used is released into the pool. The next time i get this connection from the pool the isolation level is already SERIALIZE. This is not what i wanted to achieve.
    It has to be possible to change the isolation level for transaction, isn´t it?
    Here is the code, that i use. The ConnectionManager gets the connection from a connection pool i configured in the jdbc connector service. Excep for this issue any other operation works fine.
                    ConnectionManager connectionManager = new ConnectionManager();
              Connection con = null;
              int transactionIsolationLevel = 0;
              Queue queue = null;
              List list = null;
              try {
                   con = connectionManager.getConnection();
                   transactionIsolationLevel = con.getTransactionIsolation();
                   if( logger.isInfoEnabled())
                        logger.info(LOGLOC + "ISOLATION_LEVEL default: " + transactionIsolationLevel);
                   // auskommentiert für RE
                   con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
                   con.setAutoCommit( false );
              QueueManager queueManager = new QueueManager();
              list = queueManager.GetQueueEntriesBySizeGroups( con, small, medium, large, serverNode );
              con.commit();
              } catch (ClassNotFoundException cnfe) {
                   logger.error(LOGLOC + "Exception setting up transaction context for queue service!", cnfe);
                   handleExceptions(queue, cnfe);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } catch (SQLException sqle) {
                   logger.error(LOGLOC + "Exception setting up transaction context for queue service!", sqle);
                   handleExceptions(queue, sqle);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } catch (QueueManagerException qme) {
                   logger.error(LOGLOC + "Exception executing queue manager!", qme);
                   handleExceptions(queue, qme);
                   try {
                        con.rollback();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception rolling back transaction!", e);               
              } finally {
                   try {
                        con.setAutoCommit(true);
                        if( logger.isInfoEnabled())
                             logger.info(LOGLOC + "ISOLATION_LEVEL before setting default: " + con.getTransactionIsolation() + " now setting: " + transactionIsolationLevel );
                        // Auskommentiert für RE
                        con.setTransactionIsolation( transactionIsolationLevel );
                        con.close();
                   } catch (SQLException e) {
                        logger.error(LOGLOC + "Exception setting up transaction context for queue service!", e);               
    The datasource is a simple jdbc1.x Oracle Datasource with no special settings.
    In a remote debugging session i saw, that the wrapped Connection from the datasource sets the txLevel successfully, But the underlying T4Connection does not get this isolation level. Could this be a bug?
    Any hints, solutions?

  • Setting isolation level to 2.

    Hi All,
    I'm trying to use Isolation level 2 for "read committed" isolation.
    all I can find is how to set level 3 isolation (by calling setTxnSerializableIsolation(true)).
    Thanks for your help.
    ~aviron

    Hi Aviron,
    The isolation degrees are discussed in the TXN GSG guide here (chapter 4. Concurrency, Isolation):
    http://www.oracle.com/technology/documentation/berkeley-db/je/TransactionGettingStarted/BerkeleyDB-JE-Txn.pdf
    For configuring committed reads (degree 2 isolation), you can do one of the following:
    - create your transaction (txn) so that it allows committed reads, by specifying true for the TransactionConfig.setReadCommitted() call;
    - specify true on the CursorConfig.setReadCommitted() call;
    - specify LockMode.READ_COMMITTED to configure degree 2 isolation on a read-by-read basis.
    Regards,
    Andrei

  • How to set isolation level for BMP

    Hi.
    We're trying to avoid the ORA-08177 by setting the isolation level in the weblogic-ejb-jar.xml
    to READ_COMMITED
    Still (looking in the jdbc.log) it seems that weblogic set the transaction isolation
    level to SERIALIZABLE
    The xml :
    <weblogic-enterprise-bean>
    <ejb-name>Account</ejb-name>
    <caching-descriptor>
    <max-beans-in-cache>100</max-beans-in-cache>
    <idle-timeout-seconds>600</idle-timeout-seconds>
    <cache-strategy>Read-Write</cache-strategy>
    </caching-descriptor>
    <persistence-descriptor>
    <delay-updates-until-end-of-tx>true</delay-updates-until-end-of-tx>
    <finders-call-ejbload>false</finders-call-ejbload>
    </persistence-descriptor>
    <clustering-descriptor>
    <home-is-clusterable>false</home-is-clusterable>
    <home-load-algorithm>round-robin</home-load-algorithm>
    </clustering-descriptor>
    <enable-call-by-reference>false</enable-call-by-reference>
    <jndi-name>Account</jndi-name>
    <transaction-isolation>
         <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
    <method><ejb-name>Account</ejb-name><method-name>*</method-name></method>
    </transaction-isolation>
    </weblogic-enterprise-bean>
    Regards

    When I marked all the beans with READ_COMMITED it works.

  • Setting Isolation levels

    We have a window service which is responsible to send SMS to users.
    We have 20 instance running as a window service which hits a single table “Tab1”.
    I have implemented isolation level – “SET TRANSACTION ISOLATION LEVEL SERIALIZABLE”, but it is not working because 20 instance is reading a single record at the same time and thus sending 20 SMS to single user.
    I want that if 20 instances read the same record, only one should send the SMS and not all.
    Please advice what can be done..
    We have these 20 instances to speed up the process of sending SMS from the table... so we cannot just rely on one service

    SERIALIZABLE only means that until you commit, SQL Server guarantees that the result set will be the same if you repeat the query. It does not perform any updates or lock a row for reacing by other users.
    It sounds like you have some sort of a queue. Thus, you should look into Service Broker.
    In the meanwhile you can try:
    BEGIN TRANSACTION
    SELECT TOP(1) .... FROM SMS_table WITH (READPAST)
    -- Send your SMS here
    UPDATE tbl SET fetched = 1 WHERE ...
    COMMIT TRANSACTIOn
    Don't use SERIALIZABLE, but stick to READ COMMITTED.
    Erland Sommarskog, SQL Server MVP, [email protected]

  • 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

Maybe you are looking for