Debugging the isolation level

          Does anyone know of a way to capture the current isolation level for a given transaction,
          in particular w/ a CMP entity bean?
          I'm using the P6SPY driver to capture debug information, but I never see a call
          to Connection.setTransactionIsolation(). Therefore, I have no way to know if
          my transaction is running with Serializable level, the level I've set in my weblogic-ejb-jar.xml
          file.
          Running WLS 6.1 and JConnect 5.5.
          Thanks,
          Jim

          Just tried the code below. Compiles -- that id good ;)
          When I'm outside transaction I get weblogic.transaction.TxHelper.getTransaction()
          == null.
          That is to be expected.
          When I'm inside transaction the property value is null. Properties that I can
          get:
          [0] key
          weblogic.transaction.name val [EJB om.moveitonline.framewo
          [1] key weblogic.jdbc val t3://10.1.26.51:7001.
          Questions:
          a) How to get the isolation level anyway?
          b) What are the integer values for isolation levels (i.e. constants)?
          Rob Woollen <[email protected]> wrote:
          >Try this:
          >
          >Integer iso =
          >weblogic.transaction.TxHelper.getTransaction().getProperty(weblogic.transaction.TxConstants.ISOLATION_LEVEL);
          >
          >-- Rob
          >
          >
          >Jim clark wrote:
          >> Does anyone know of a way to capture the current isolation level for
          >a given transaction,
          >> in particular w/ a CMP entity bean?
          >>
          >> I'm using the P6SPY driver to capture debug information, but I never
          >see a call
          >> to Connection.setTransactionIsolation(). Therefore, I have no way
          >to know if
          >> my transaction is running with Serializable level, the level I've set
          >in my weblogic-ejb-jar.xml
          >> file.
          >>
          >> Running WLS 6.1 and JConnect 5.5.
          >>
          >> Thanks,
          >> Jim
          >

Similar Messages

Setting the isolation level in Toplink or in my EJB beans?

Hi,
Seems like you can set the isolation levels in both Toplink and in the deployment descriptor of your ejb project.
What is the recommended place to specify the isolation level settings?
With kind regards.

Hi,
Seems like you can set the isolation levels in both Toplink and in the deployment descriptor of your ejb project.
What is the recommended place to specify the isolation level settings?
With kind regards.

Setting the Isolation Level to Read Uncommitted

Hello All,
We are using BO XI r3 and SQL Server 2008. I would like to change the isolation level of the connection to read uncommitted. There are 2 options that i could by Googling..
1. Making changes in the SBO file... this didnt work
2. Making changes in the connectinit... even this didnt work
i am not sure if there is anything else to done... but i tried quering a table with a lock, the report got stuck so i am guessing that the settings didnt work

Hi
this is the only method for changing the transaction isolation level.
Locate the path to your odbc.sbo file
Click the connection in UDT and when server responds Click the Details button
scroll down to the sbo line
That is the file location of your sbo file (this will be the same on client and server)
This change needs to be done, for client and servers both
The isolation can only be set for the global connection. Not per universe.
Locate the file and make a backup before making any changes
Find the Tag
<DataBase Active="Yes" Name="MS SQL Server 2008">
Below that tag should be a "Force SQLExecute" Parameter
Like This
<Parameter Name="Force SQLExecute">Procedures</Parameter>
ADD this line
<Parameter Name="Transaction Isolation Level">READ_UNCOMMITTED</Parameter>
Save the odbc.sbo
After client and server are changed
Restart SIA
Run the webi document again.
Locations of the sbo file:
R2: <Installation Directory>:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\win32_x86\dataAccess\connectionServer\rdbms
R3: <Installation Directory>:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86\dataAccess\connectionServer\rdbms
BI4: <Installation Directory>:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\dataAccess\connectionServer\rdbms
To make these changes effect, you have to restart ‘CMS server’, ‘the Connection Servers’, ‘Webi Report Server’ from ‘Central Configuration Manager’ (CCM).
Information is available in the Data Access guide
Jacqueline

How to set the isolation level on Entity EJBs

I am using 10.1.3.3 of the OC4J app server.
I am creating an application that uses EJB 2.1.
I am trying to set the isolation levels on the EJBs to either serializable or repeatable read.
When i deploy the EAR file from the OC4J admin console, i can set the isolation level property on the EJB's however when i inspect the orion-ejb-jar.xml file I do not see the isolation level being set. Furthermore, i tried to manually change the isolation setting by editing the orion-ejb-jar.xml and adding the isolation="serialiable" attribute on the entity bean descriptor. I then stopped and restarted the server. I noticed that my change was no longer in the file.
Can someone please let me know how to solve this problem and set the isolation level on Entity EJBs . Thanks

I find it at ejb.pdf from BEA.
          The transaction-isolation stanza can contain the elements shown here:
          <transaction-isolation>
          <isolation-level>Serializable</isolation-level>
          <method>
          <description>...</description>
          <ejb-name>...</ejb-name>
          <method-intf>...</method-intf>
          <method-name>...</method-name>
          <method-params>...</method-params>
          </method>
          </transaction-isolation>
          "Hyun Min" <[email protected]> wrote in message
          news:3c4e7a83$[email protected]..
          > Hi!
          >
          > I have a question.
          > How to set the transaction isolation level using CMT in descriptor?
          >
          > The Isolation level not supported in CMT?
          >
          > Thanks.
          > Hyun Min
          >
          >

Crrystal Reports using ADO. How do you Change the Isolation Level?

Post Author: jmetaxas
CA Forum: Data Connectivity and SQL
Crrystal Reports using ADO. How do you Change the Isolation Level? I found a knowledge base article that allows you to change it for ODBC. But nothing on ADO. I kicked around changing the reports to ODBC but even then the keys described in the article do no exist. Any suggestions?
Thanks,
John Metaxas

T-Bob wrote:
I want to make sure that points 2&3 are at the same level, so I can just move the envelope region between them up and down to change the volume. Any quick way to do this to speed up my process?
Specifically to address this point: if you mouse over the audio levels' rubber band segment BETWEEN your points 2) and 3) until the cursor changes to an up/down adjustment arrow ⬍, and move it up/down, it will adjust BOTH the levels at 2) and 3), maintaining the relative difference between them (or, if points 2) and 3) start at the same level, this adjustment will keep them equal as you drag them both up/down together in one action.)
As usual, much easier to DO it, rather than describe it!

What's the Isolation Level of account transaction

SERIALIZABLE or READ COMMITED ?

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

How to change the transaction isolation level of a CMP?

How to change the transaction isolation level of a CMP from SUN's Deployment Tool? So far I can't find any entry for this setting.

Anuradha W wrote:
That means, currently the only way tospecify the transaction level is through
weblogic-ejb-jar.xml deployment descriptor?
for WLS-generated code, yes.Somewhat related to this question, we have written a standalone testcase to reproduce this issue we have been having. Basically, the issue is that even though we configure the isolation level to a non-default one in the deployment descriptor, the connections returned by the datasource seem to be having the default (which is Read Committed). The DBMS is DB2.
weblogic-ejb-jar.xml has the following set:
<isolation-level>TransactionRepeatableRead</isolation-level>
And we printed the isolation level of the connection returned from a method in the EJB, but the isolation level is still the default. I can share the code to reproduce the problem if you want to take a look at it. Please let me know how I can get that across to you.
Thanks,
AnuradhaIf you are using our JDBC driver for DB2, or can switch to it,
just for a test, there is some debug I'd like from you.
Joe

How to Set the Transaction Isolation Level in WebLogic?

Is there a way to set the transaction isolation level in WebLogic 9.2 or WebLogic 10?
For an example say, we have an application which is supported for several database platforms. Without setting the transaction isolation level in DBMS level, is there a way to specify this in WebLogic to make it common for all the DBMS type?
And I found a way to change the transaction isolation level in WebSphere application server using a property called webSphereDefaultIsolationLevel.
[url http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21224492]http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21224492
Is there a way to do the same thing in WebLogic application server 9.2 or 10?

Anuradha W wrote:
That means, currently the only way tospecify the transaction level is through
weblogic-ejb-jar.xml deployment descriptor?
for WLS-generated code, yes.Somewhat related to this question, we have written a standalone testcase to reproduce this issue we have been having. Basically, the issue is that even though we configure the isolation level to a non-default one in the deployment descriptor, the connections returned by the datasource seem to be having the default (which is Read Committed). The DBMS is DB2.
weblogic-ejb-jar.xml has the following set:
<isolation-level>TransactionRepeatableRead</isolation-level>
And we printed the isolation level of the connection returned from a method in the EJB, but the isolation level is still the default. I can share the code to reproduce the problem if you want to take a look at it. Please let me know how I can get that across to you.
Thanks,
AnuradhaIf you are using our JDBC driver for DB2, or can switch to it,
just for a test, there is some debug I'd like from you.
Joe

Why can't I change the transaction isolation level?

I was trying to change the transaction isolation level from an EJB. My source codes are shown as the follows:
======================================================
/*********************** Database Routines *************************/
private void makeConnection() {
try {
InitialContext ic = new InitialContext();
DataSource ds = ( DataSource )ic.lookup( dbName );
con = ds.getConnection();
DatabaseMetaData dmd = con.getMetaData();
show_supported_trans_levels( dmd );
int status = con.getTransactionIsolation();
System.out.print( "1. " );
disp_tx_status( status );
System.out.println( "con.isReadOnly() = " + con.isReadOnly() );
con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE );
System.out.print( "2. " );
disp_tx_status( status );
} catch( SQLException ex ) {
System.err.println( "SQLException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
} catch( NamingException ex ) {
System.err.println( "NamingException: " + ex.toString() );
throw new EJBException("Unable to connect to database. " +
ex.getMessage());
private void disp_tx_status( int status )
System.out.print( "Transaction Status: " );
switch( status )
case( Connection.TRANSACTION_READ_UNCOMMITTED ):
System.out.println( "TRANSACTION_READ_UNCOMMITTED" );
break;
case( Connection.TRANSACTION_READ_COMMITTED ):
System.out.println( "TRANSACTION_READ_COMMITTED" );
break;
case( Connection.TRANSACTION_REPEATABLE_READ ):
System.out.println( "TRANSACTION_REPEATABLE_READ" );
break;
case( Connection.TRANSACTION_SERIALIZABLE ):
System.out.println( "TRANSACTION_SERIALIZABLE" );
break;
case( Connection.TRANSACTION_NONE ):
System.out.println( "TRANSACTION_NONE" );
break;
default:
System.out.println( "UNKNOWN" );
break;
private void show_supported_trans_levels( DatabaseMetaData dmd ) throws SQLException
System.out.println( "List of Supported Transaction Isolation Levels: " );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_UNCOMMITTED ) )
System.out.println( "TRANSACTION_READ_UNCOMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_UNCOMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_READ_COMMITTED ) )
System.out.println( "TRANSACTION_READ_COMMITTED is supported!" );
else
System.out.println( "TRANSACTION_READ_COMMITTED is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_REPEATABLE_READ ) )
System.out.println( "TRANSACTION_REPEATABLE_READ is supported!" );
else
System.out.println( "TRANSACTION_REPEATABLE_READ is unsupported!" );
if( dmd.supportsTransactionIsolationLevel( Connection.TRANSACTION_SERIALIZABLE ) )
System.out.println( "TRANSACTION_SERIALIZABLE is supported!" );
else
System.out.println( "TRANSACTION_SERIALIZABLE is unsupported!" );
=========================================================
However, I encountered the following exception when running at the highlighted statement:
======================================================
SQLException: java.sql.SQLException: Transaction manager errors. statement not allowed in XA Session.
======================================================
To my surprise, the isolation level TRANSACTION_SERIALIZABLE is supported from the database vendor. So why can't I change the transaction isolation level?

You can change the setting, you may need to click the lock at the bottom of the preference pane. Be careful what you download and install, Gatekeeper is there to help you. OS X: About Gatekeeper - Apple Support

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?

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

How do you determine a process or sessions isolation level.

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

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

Setting Isolation level 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 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.

Setting transaction isolation level in Weblogic 5.1

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


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

Debugging the isolation level

Similar Messages

Maybe you are looking for