Setting JDBC Transaction Isolation

https://community.jboss.org/wiki/ConfigDataSources
As explained in the above URL, with JBoss, you can set the JDBC transaction isolation level in the xml file that contains the JDBC connection information.
I've been doing some googling, but I'm not clear on how this can be done with WebLogic. Is there some kind of external file where you can set the JDBC transaction isolation level as with JBoss, or is this some kind of change that can only be made in the application code or in some file contained within the application archive file (ear, war, etc.)?

You can set the isolation in the deployment override weblogic-ejb-jar.xml
- http://docs.oracle.com/cd/E21764_01/web.1111/e13719/ejb_jar_ref.htm#i1116237
- http://docs.oracle.com/cd/E21764_01/web.1111/e13719/ejb_jar_ref.htm#i1219612

Similar Messages

  • 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

  • JDBC transaction isolation

    Isolation levels are:
    commited, repeatable read, uncomitted and serializable.
    As a Java programmer, where will we specify these attributes?

    kasim wrote:
    I am using just JDBC, when i program using JDBC where i need to specify these?Sorry about the previous comment. I couldn't resist.
    Anyway, see java.sql.Connection and set/get TransactionIsolation: http://java.sun.com/javase/6/docs/api/java/sql/Connection.html

  • Setting transaction isolation levels in WAS5

    I think I'm missing something pretty easy. How can I set the isolation
    levels for the containter managed transactions on my beans?
    Specifically, I want to set soem lookup methods on my Sessions beans
    to TRANSACTION_REPEATABLE_READ. I've already put the
    container-transaction blocks in my ejb-jar.xml
    Does Websphere 5 have something akin to WebLogic's
    weblogic-ejb-jar.xml where you can set additional parameters like
    this? Do I have to use a tool like WSAD to specify this? The AAT
    doesn't seem to have this option.
    Thanks,
    James Lynn

    Hi Slava, Ryan,
    We haven't looked at 8.1 yet since our release cycle wouldn't allow us
    to move to 8.1 until at least June anyway, but even if the problems was
    fixed there it took BEA support more than 6 months (I opened the case on
    Sep 23 2002 and only this week I got the patch that I haven't even tried
    to test to see if it works) to issue a patch for such a small problem.
    The server would just check if the Oracle XA driver was being used and
    no matter what version would just throw an exception if you try to set
    the transaction isolation level saying that the feature in the Oracle
    8.1.7 driver was broken... (although you might be using 9.x or even a
    pre-8.1.7 driver)...
    So this is about it.
    And Slava, I've tried pushing a case harder only to end up with BEA
    support trying to convince me that I was misinterpreting the JDBC spec
    when it was not true, so I just gave up. The main goal of BEA support in
    all of our experience has been that they don't try to solve the cases
    but close them.
    That's my and some of my colleagues personal views anyway, you don't
    have to share them.
    Regards,
    Dejan
    Slava Imeshev wrote:
    Hi Deyan,
    Sorry for the delay. Could you give us more details about CR090104?
    I've got some feedback in XA area, not sure if it was a related case.
    Also, I've never had any problems with weblogic CCE, so you may want
    to push your case a little harder.
    As per the bold statement - the initial question was about functionality
    available in weblogic but not available in websphere - it can't be more
    bold :)
    Regards,
    Slava Imeshev
    "Deyan D. Bektchiev" <[email protected]> wrote in message
    news:[email protected]...
    This is a very bold statement Slava, considering that with Oracle XA
    driver you cannot even set the transaction isolation level because of a
    Weblogic bug (CR090104 that has been open for more than 6 months
    already)...
    Dejan
    Slava Imeshev wrote:
    Hi James,
    "James F'jord Lynn" <[email protected]> wrote in message
    news:[email protected]...
    I think I'm missing something pretty easy. How can I set the isolation
    levels for the containter managed transactions on my beans?
    Specifically, I want to set soem lookup methods on my Sessions beans
    to TRANSACTION_REPEATABLE_READ. I've already put the
    container-transaction blocks in my ejb-jar.xml
    Does Websphere 5 have something akin to WebLogic's
    weblogic-ejb-jar.xml where you can set additional parameters like
    this? Do I have to use a tool like WSAD to specify this? The AAT
    doesn't seem to have this option.
    My guess here is that it's a signal that this is a last chance
    for you to abandon WebSphere and return back to WebLogic's
    safe harbor.
    Regards,
    Slava Imeshev

  • Setting transaction isolation level rises ORA-02089 error

    Hello
    We have configured a distributed transaction in our application server and
    we are using openjpa 1.2.1 and Glassfish application server and Oracle 11g as DB server. Although the default behavior of transaction locking must be optimistic,
    it seems that pessimistic locking has been happened.
    It is found that Row Lock contention happens in a specific table.
    This is the exception :
    java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock
    Already all the following properties have been set for openjpa.
    1. <persistence-unit name="JPXA" transation-type="JTA">
    2. <property name="openjpa.TransactionMode" value="managed"/>
    You can try a plug-in string to lookup the TM in JNDI (the value is the JNDI name of GlassFish TM as per Google search)
    3. <property name="openjpa.ManagedRuntime"
    value="jndi(TransactionManagerName=java:appserver/TransactionManager)"/>
    Following searching about this locking problem, we found that we should add two more properties for openjpa as listed below.
    <property name="openjpa.LockManager" value="version" />
    <property name="openjpa.jdbc.TransactionIsolation" value="read-committed" />
    but this time by setting the transaction isolation level, we have got another error: org.apache.openjpa.persistence.PersistenceException: ORA-02089: COMMIT is not allowed in a subordinate session.
    Thanks for any help.
    Regards,
    Sargol

    Hello
    We have configured a distributed transaction in our application server and
    we are using openjpa 1.2.1 and Glassfish application server and Oracle 11g as DB server. Although the default behavior of transaction locking must be optimistic,
    it seems that pessimistic locking has been happened.
    It is found that Row Lock contention happens in a specific table.
    This is the exception :
    java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock
    Already all the following properties have been set for openjpa.
    1. <persistence-unit name="JPXA" transation-type="JTA">
    2. <property name="openjpa.TransactionMode" value="managed"/>
    You can try a plug-in string to lookup the TM in JNDI (the value is the JNDI name of GlassFish TM as per Google search)
    3. <property name="openjpa.ManagedRuntime"
    value="jndi(TransactionManagerName=java:appserver/TransactionManager)"/>
    Following searching about this locking problem, we found that we should add two more properties for openjpa as listed below.
    <property name="openjpa.LockManager" value="version" />
    <property name="openjpa.jdbc.TransactionIsolation" value="read-committed" />
    but this time by setting the transaction isolation level, we have got another error: org.apache.openjpa.persistence.PersistenceException: ORA-02089: COMMIT is not allowed in a subordinate session.
    Thanks for any help.
    Regards,
    Sargol

  • How to set Transaction isolation level in Weblogic 11g

    How do I set the transaction isolation level in Weblogic?
    Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
    Can I set this up as a property in the JDBC datasource setup?
    Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
    Currently I get the following message if I don't set the isolation level:
    Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
    What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
    I think the issue is related to the isolation level or the transaction time out being too low.
    Any ideas?
    BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
    Thanks
    Edited by: rrivera on Jun 2, 2010 9:18 AM

    How do I set the transaction isolation level in Weblogic?
    Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
    Can I set this up as a property in the JDBC datasource setup?
    Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
    Currently I get the following message if I don't set the isolation level:
    Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
    What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
    I think the issue is related to the isolation level or the transaction time out being too low.
    Any ideas?
    BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
    Thanks
    Edited by: rrivera on Jun 2, 2010 9:18 AM

  • Setting transaction isolation level in a session bean

    Hi all!
    In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
    The idea is to prevent lost update on database when multiple accesses occur concurrently.
    Thanks in advance for your patience,
    Tommaso

    Hi all!
    In a stateless session bean (EJB3) with container managed transactions I need to set the transaction isolation level to SERIALIZABLE.
    The idea is to prevent lost update on database when multiple accesses occur concurrently.
    Thanks in advance for your patience,
    Tommaso

  • Setting transaction isolation level for jDriver Oracle/XA

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

    Ian,
    The default for Oracle (any version) is ReadCommitted. The only other
    isolation level Oracle supports is Serializable but it's implemented in
    such a way that you will be allowed to continue until commit time and
    only then you might get an exception stating the the access for that
    transaction could not be serialized.
    I don't know for the jDriver but if you use the Oracle Thin XA driver
    even if you set the isolation level in your descriptor you will get an
    exception from Weblogic. It is a Weblogic bug and you can contact
    [email protected] to get a patch.
    Regards,
    Dejan
    IJ wrote:
    edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
    if using jDriver for Oracle/XA you can not set the transaction isolation level
    for a
    transaction and that 'Transactions use the transaction isolation level set on
    the connection
    or the default transaction isolation level for the database'. Does this mean that
    you shouldn't try to set it programatically (fair enough) or that you can't set
    it in the weblogic deployment descriptor either? Also anybody got any idea what
    the default is likely to be if you are using
    an Oracle 9iR2 database?

  • Setting Transaction Isolation

    Hi,
    Is there an OCCI API to set the transaction isolation level for a connection? (eg, TRANSACTION_READ_COMMITTED, TRANSACTION_SERIALIZABLE, etc)
    Thanks,
    Nilofer

    There is no API, you have to execute the corresponding SQL statements through Statement::execute :-
    stmt->execute("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");
    Regards,
    Shankar

  • Why encounter errors while setting transaction isolation level?

    When attempting to set the transaction isolation level within an EJB, I encountered the following exception from the server log:
    ===========================================================
    [#|2006-05-30T15:08:45.906+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    Enter ejbCreate( 100, Duke, Earl, 0.00 ):|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    List of Supported Transaction Isolation Levels: |#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    TRANSACTION_READ_UNCOMMITTED is supported!|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    TRANSACTION_READ_COMMITTED is supported!|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    TRANSACTION_REPEATABLE_READ is supported!|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    TRANSACTION_SERIALIZABLE is supported!|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    1. |#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|Transaction Status: |#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|TRANSACTION_READ_COMMITTED|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.stream.out|_ThreadID=25;|
    con.isReadOnly() = false|#]
    [#|2006-05-30T15:08:45.937+0800|WARNING|sun-appserver-pe8.1_02|javax.enterprise.system.stream.err|_ThreadID=25;|
    SQLException: java.sql.SQLException: Transaction manager errors. statement not allowed in XA session.|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=25;|EJB5018: An exception was thrown during an ejb invocation on [SavingsAccountBean]|#]
    [#|2006-05-30T15:08:45.937+0800|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.container.ejb|_ThreadID=25;|
    javax.ejb.EJBException: ejbCreate: Unable to connect to database. Transaction manager errors. statement not allowed in XA session.
    at SavingsAccountBean.ejbCreate(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at com.sun.enterprise.security.SecurityUtil$2.run(SecurityUtil.java:153)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.enterprise.security.application.EJBSecurityManager.doAsPrivileged(EJBSecurityManager.java:950)
    at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:158)
    at com.sun.ejb.containers.EJBHomeInvocationHandler.invoke(EJBHomeInvocationHandler.java:170)
    at $Proxy60.create(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:123)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:648)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1709)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1569)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:951)
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:721)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:469)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1258)
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:409)
    |#]===========================================================
    But from the above log messages, all transcation isolation levels are supported. The relevant source codes are:
    /*********************** 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;
    Who can help me?

    Try the following forum (about EJB technology)
    http://forum.java.sun.com/forum.jspa?forumID=13

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

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

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

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

  • Transaction Isolation Levels in weblogic-cmp-rdbms-jar.xml

    Hi All,
    Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
    isolation levels for the methods in the
    weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
    in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
    the isolation levels in these two ways.
    Help me asap.

    The CMP setting has been deprecated. You can set it for all types of
    EJBs in the weblogic-ejb-jar.xml
    -- Rob
    chandru wrote:
    Hi All,
    Iam using ejb 1.1 specification with weblogic 5.1. We can set the transaction
    isolation levels for the methods in the
    weblogic-ejb-jar.xml. There is also a provision for setting this isolation level
    in the weblogic-cmp-rdbms-jar.xml. Now is there any difference between setting
    the isolation levels in these two ways.
    Help me asap.

  • Locking issues with transaction-isolation levels

              I believe that my program is suffering from some sort of deadlock, and I was hoping
              for some feedback.
              I am helping to develop a trading system
              using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
              called LiveOrder that exposes several finder methods, most of which return java.util.Collections
              of LiveOrder EJBs.
              In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
              finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
              isn't really supported by Oracle), in an effort to eliminate phantom reads, which
              occur frequently if I do not use this isolation level. These finders all use transaction
              attribute 'Required'.
              It is my understanding that any transaction that calls any of these finders either
              will lock the database if no other transaction already owns the lock, or will
              wait until the lock is released if another transaction owns that lock. It also
              is my understanding that a transaction that owns a lock will always release any
              locks acquired upon expiration of that transaction (whether that be via commit
              or via rollback).
              However, this doesn't always appear the case: I have noticed occassionally that
              several clients "hang," as they wait for the lock that, for some reason, is not
              being released by its transaction. There do not appear to be any exceptions thrown
              by the system prior to the system hanging, and the Weblogic administration tool
              states that all transactions have been committed.
              If it helps, I have included the general algorithm for the main (i.e., most expensive)
              transaction:
              1. a client calls a stateless session EJB's processOrder method (which should
              implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
              2. the transaction invokes the LiveOrder finder method (this should lock the DB,
              so subsequent callers should block until the lock is released).
              3. the transaction invokes another LiveOrder finder method, returning a separate
              set of data.
              4. the transaction invokes a finder method from a separate entity EJB (called
              Security), which maps to a "read-only" table in the DB (default transaction-isolation
              level, Required attribute).
              5. the transaction invokes a finder method from yet another separate entity EJB
              (called SecurityMarketValues), which maps to some other table (not read-only)
              in the DB (again, default transaction-isolation level, Required attribute).
              6. the transaction writes to the SecurityMarketValues entity EJB.
              7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
              8. the transaction ends by exiting method processOrder (thus releasing the locks
              on the LiveOrder table in the DB).
              In the system, there also exist other transactions that occassionally call the
              LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
              order table (i.e., these transactions do not make calls to other DB tables, and
              close transactions almost immediately after starting them)
              Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
              ideas? I'm running out...
              

    Jon,
              If there was an Oracle deadlock the DB would resolve it momentarily and
              will ultimately choose one transaction and throw an exception so it's
              not a DB deadlock.
              Take a thread dump at the very moment your system seems to be hanging
              and look at what the threads are doing.
              From your description it's not very unlikely that those threads of
              yours that take snapshots of the data will not disrupt the transactions
              so you may be surprised by the thread dumps that this is actually what
              happens -- those snapshot thread wait for some lock while holding locks
              needed by you other threads and it just slows down the system.
              Regards,
              Dejan
              Jon Gadzik wrote:
              >I believe that my program is suffering from some sort of deadlock, and I was hoping
              >for some feedback.
              >
              >I am helping to develop a trading system
              >using EJBs, Oracle 9i, and Bea Weblogic 7.0. The system provides an entity EJB
              >called LiveOrder that exposes several finder methods, most of which return java.util.Collections
              >of LiveOrder EJBs.
              >
              >In weblogic-ejb-jar.xml, I have set the transaction isolation-levels for these
              >finders to TRANSACTION_READ_COMMITTED_FOR_UPDATE (b/c TRANSACTION_SERIALIZABLE
              >isn't really supported by Oracle), in an effort to eliminate phantom reads, which
              >occur frequently if I do not use this isolation level. These finders all use transaction
              >attribute 'Required'.
              >
              >It is my understanding that any transaction that calls any of these finders either
              >will lock the database if no other transaction already owns the lock, or will
              >wait until the lock is released if another transaction owns that lock. It also
              >is my understanding that a transaction that owns a lock will always release any
              >locks acquired upon expiration of that transaction (whether that be via commit
              >or via rollback).
              >
              >However, this doesn't always appear the case: I have noticed occassionally that
              >several clients "hang," as they wait for the lock that, for some reason, is not
              >being released by its transaction. There do not appear to be any exceptions thrown
              >by the system prior to the system hanging, and the Weblogic administration tool
              >states that all transactions have been committed.
              >
              >If it helps, I have included the general algorithm for the main (i.e., most expensive)
              >transaction:
              >
              >1. a client calls a stateless session EJB's processOrder method (which should
              >implicitly start a new transaction, b/c this method has attibute 'RequiresNew')
              >
              >2. the transaction invokes the LiveOrder finder method (this should lock the DB,
              >so subsequent callers should block until the lock is released).
              >
              >3. the transaction invokes another LiveOrder finder method, returning a separate
              >set of data.
              >
              >4. the transaction invokes a finder method from a separate entity EJB (called
              >Security), which maps to a "read-only" table in the DB (default transaction-isolation
              >level, Required attribute).
              >
              >5. the transaction invokes a finder method from yet another separate entity EJB
              >(called SecurityMarketValues), which maps to some other table (not read-only)
              >in the DB (again, default transaction-isolation level, Required attribute).
              >
              >6. the transaction writes to the SecurityMarketValues entity EJB.
              >
              >7. the transaction writes to the LiveOrders retrieved from steps 2 and 3.
              >
              >8. the transaction ends by exiting method processOrder (thus releasing the locks
              >on the LiveOrder table in the DB).
              >
              >
              >In the system, there also exist other transactions that occassionally call the
              >LiveOrder EJB finder methods, but only briefly to take a "snapshot" of the live
              >order table (i.e., these transactions do not make calls to other DB tables, and
              >close transactions almost immediately after starting them)
              >
              >Like I mentioned before, the system sometimes works, and sometimes it hangs. Any
              >ideas? I'm running out...
              >
              >
              >
              >
              

  • Transaction Isolation Level for EJB methods

    L.S.
    I just found out the in OC4J one can not set the transaction isolation level on ejb methods. Moreover one needs to revert to bean managed transaction (manual coding of the ALL transaction logic) to set the isolation level.
    On entity beans one can only set the isolation level for the whole bean (not on individual methods), and in session beans there is no way at all to set the isolation level.
    This is on shear contract to all other application servers I used before (there one can declaratively set the isolation level for a ejb method, both in session and in entitybean deployment descriptors)
    Is it foreseen in a future release to include such a valuable feature will be provided by oc4j?
    Note that I was VERY surprised that OC4J could not handle this (I checked the j2ee spec, but admittedly the spec is a little vague about this support and makes it vendor dependent. the j2ee spec does not mandate this, except for CMP entity beans, but includes some suggestions on this ability. But most other application servers implemented the ability)
    Regadrs,
    Erik

    Hello Erik --
    I think we met in Perth recently?
    Anyway, your information is correct.
    We can set the transaction isolation level for each entity bean, at the bean level. We don't have for the specification of method level isolation settings -- I'd be interested to hear how you would like/do use this. What behaviour do you expect to see when a transaction is started that spans multiple methods on a bean with different declared isolation levels.
    For session beans, we do not currently have the ability to declaratively specify the isolation level to use for the bean. I know this is not in the forthcoming 904 release, and will to check what is beyond that.
    As you point out, this can be done programatically using the Connection.setIsolationLevel() method on any connections you are using from within the session bean.
    I'd would like to log an enhancement request for you for this functionality. Can you send me an email at [email protected] and we'll take it offline.
    -steve-

Maybe you are looking for

  • Cant send Email when using WIFI

    My primary internet connection is my G4 and a 24.4K dial up. I bought a Dual USB port iBook with 10.4.11 to take to the local library download large files I am sometimes sent. The iBook connects normally on the WIFI, I can browse and work web sites.

  • Can movies play at 1080

    I read this in the HDMI dongle "Mirroring supported only by iPad 2 and iPhone 4S. Video out supports up to 1080p for iPad 2 and iPhone 4S and up to 720p for iPad, iPhone 4 and iPod touch (4th generation). Movies play at up to 720p." (iPad2 HDMI dongl

  • Homepage

    When I want to go back to my home screen, pressing the button doesn't work all of the time.  Actually not very often.  Is there something I can do to fix it?

  • Combo chart - different colors for Bar/Line

    Hi, In a combo chart is it possible to have different colors for bar and lines......................In our report- combo charts the intersection of bar/line is NOT visible beacuse of same color.

  • Sendmail sends mail to yahoo but not local domain

    Hi, I havent worked much on sendmail at all, and as I know it its already configured in Solaris 10 and we just have to put in the relevant entries of DNS etc to make it work. Now the problem is when I use the command mailx to send mail, it is sending