java.sql.SQLException: [SQL0204] SYSTABLES in SYSIBM type *FILE not found. You can resolve this issue by creating an extension of the DB2Dictionary that looks something like this: public class AS400Dictionary extends com.solarmetric.kodo.impl.jdbc.schema.dict.DB2Dictionary { public AS400Dictionary () { setValidateConnectionSQL ("some SELECT that is fast and valid"); } } The validate SQL is used from time to time when borrowing items from the connection pool to ensure that a connection is really alive, since the Connection.isClosed() method is notoriously bad at truly identifying live connections. -Patrick On Mon, 14 Jul 2003 10:54:05 +0000, Harald wrote: Hello, I was using kodo 2.4.2 with with an as400 db2 database (DB2 for OS/400 JDBC Driver). This worked fine for me. After upgrading to to kodo 2.5.2 i get the following exception: A connection could not be obtained in the specified login time of 30 seconds. [code=0;state=null] NestedThrowables: com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper: [SQL=SELECT .... A connection could not be obtained in the specified login time of 30 seconds.

Oracle Community | 3004 | 1 decade ago
  1. 0

    connection problem with as400 after upgrade to 2.5.2

    Oracle Community | 1 decade ago | 3004
    java.sql.SQLException: [SQL0204] SYSTABLES in SYSIBM type *FILE not found. You can resolve this issue by creating an extension of the DB2Dictionary that looks something like this: public class AS400Dictionary extends com.solarmetric.kodo.impl.jdbc.schema.dict.DB2Dictionary { public AS400Dictionary () { setValidateConnectionSQL ("some SELECT that is fast and valid"); } } The validate SQL is used from time to time when borrowing items from the connection pool to ensure that a connection is really alive, since the Connection.isClosed() method is notoriously bad at truly identifying live connections. -Patrick On Mon, 14 Jul 2003 10:54:05 +0000, Harald wrote: Hello, I was using kodo 2.4.2 with with an as400 db2 database (DB2 for OS/400 JDBC Driver). This worked fine for me. After upgrading to to kodo 2.5.2 i get the following exception: A connection could not be obtained in the specified login time of 30 seconds. [code=0;state=null] NestedThrowables: com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper: [SQL=SELECT .... A connection could not be obtained in the specified login time of 30 seconds.
  2. 0

    error when connect to sqlserver

    Oracle Community | 1 decade ago | 3004
    java.sql.SQLException: [Microsoft][SQLServer JDBC Driver]Connection timed out: connect
  3. 0

    JDBC And Concurrency Issues

    Oracle Community | 2 decades ago | 3004
    java.sql.SQLException: The coordinator has rolled back the transaction. No further JDBC access is allowed within this transaction. You can expect this to come randomly from JTS transactional JDBC code when the transaction timeout has been reached. The JTS driver colludes with the transaction coordinator in a way that allows the coordiinator (running in a totally separate thread) do know when a given JTS/EJB transaction has not completed by the time the timeout has expired. At this point the coordinator will roll back the transaction, and close all the JDBC resources right out from under the thread running the transaction. This can occur at any time while the transaction thread is in the middle of any JDBC call at all. At this time the call in-progress, and any subsequent one if the thread running the now-defunct transaction tries it, will get this exception. As to why a given JDBC call may hang for a long time, causing the tx to timeout, it's not JDBC concurrency, it's probably DBMS concurrency that is the issue. The first place to look is in the DBMS to see whether this transaction is waiting for locks that another tx is holding. If you are running a transaction isolation level of SERIALIZABLE, that could cause very bad Oracle performance, and not even provide the benefits one would hope for with this isolation level. I recommend explicitly setting the transaction isolalation level to the default-and-only-non-buggy setting for Oracle, READ_COMMITTED. Let me know if this helps. Joe
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    JDBC And Concurrency Issues

    Oracle Community | 2 decades ago | 3004
    java.sql.SQLException: The coordinator has rolled back the transaction. No further JDBC access is allowed within this transaction. You can expect this to come randomly from JTS transactional JDBC code when the transaction timeout has been reached. The JTS driver colludes with the transaction coordinator in a way that allows the coordiinator (running in a totally separate thread) do know when a given JTS/EJB transaction has not completed by the time the timeout has expired. At this point the coordinator will roll back the transaction, and close all the JDBC resources right out from under the thread running the transaction. This can occur at any time while the transaction thread is in the middle of any JDBC call at all. At this time the call in-progress, and any subsequent one if the thread running the now-defunct transaction tries it, will get this exception. As to why a given JDBC call may hang for a long time, causing the tx to timeout, it's not JDBC concurrency, it's probably DBMS concurrency that is the issue. The first place to look is in the DBMS to see whether this transaction is waiting for locks that another tx is holding. If you are running a transaction isolation level of SERIALIZABLE, that could cause very bad Oracle performance, and not even provide the benefits one would hope for with this isolation level. I recommend explicitly setting the transaction isolalation level to the default-and-only-non-buggy setting for Oracle, READ_COMMITTED. Let me know if this helps. Joe >
  6. 0

    JDBC And Concurrency Issues

    Oracle Community | 2 decades ago | 3004
    java.sql.SQLException: The coordinator has rolled back the transaction. >>> No further JDBC access is allowed within this transaction. You can expect this to come randomly from JTS transactional JDBC code when the transaction timeout has been reached. The JTS driver colludes with the transaction coordinator in a way that allows the coordiinator (running in a totally separate thread) do know when a given JTS/EJB transaction has not completed by the time the timeout has expired. At this point the coordinator will roll back the transaction, and close all the JDBC resources right out from under the thread running the transaction. This can occur at any time while the transaction thread is in the middle of any JDBC call at all. At this time the call in-progress, and any subsequent one if the thread running the now-defunct transaction tries it, will get this exception. As to why a given JDBC call may hang for a long time, causing the tx to timeout, it's not JDBC concurrency, it's probably DBMS concurrency that is the issue. The first place to look is in the DBMS to see whether this transaction is waiting for locks that another tx is holding. If you are running a transaction isolation level of SERIALIZABLE, that could cause very bad Oracle performance, and not even provide the benefits one would hope for with this isolation level. I recommend explicitly setting the transaction isolalation level to the default-and-only-non-buggy setting for Oracle, READ_COMMITTED. Let me know if this helps. Joe

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.sql.SQLException

      [SQL0204] SYSTABLES in SYSIBM type *FILE not found. You can resolve this issue by creating an extension of the DB2Dictionary that looks something like this: public class AS400Dictionary extends com.solarmetric.kodo.impl.jdbc.schema.dict.DB2Dictionary { public AS400Dictionary () { setValidateConnectionSQL ("some SELECT that is fast and valid"); } } The validate SQL is used from time to time when borrowing items from the connection pool to ensure that a connection is really alive, since the Connection.isClosed() method is notoriously bad at truly identifying live connections. -Patrick On Mon, 14 Jul 2003 10:54:05 +0000, Harald wrote: Hello, I was using kodo 2.4.2 with with an as400 db2 database (DB2 for OS/400 JDBC Driver). This worked fine for me. After upgrading to to kodo 2.5.2 i get the following exception: A connection could not be obtained in the specified login time of 30 seconds. [code=0;state=null] NestedThrowables: com.solarmetric.kodo.impl.jdbc.sql.SQLExceptionWrapper: [SQL=SELECT .... A connection could not be obtained in the specified login time of 30 seconds.

      at com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore()
    2. com.solarmetric.kodo
      QueryImpl.execute
      1. com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExceptions.java:64)
      2. com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.executeQuery(JDBCStoreManager.java:1110)
      3. com.solarmetric.kodo.impl.jdbc.query.JDBCQuery.executeQuery(JDBCQuery.java:126)
      4. com.solarmetric.kodo.query.QueryImpl$DatastoreQueryExecutor.executeQuery(QueryImpl.java:1554)
      5. com.solarmetric.kodo.query.QueryImpl.executeQueryWithMap(QueryImpl.java:675)
      6. com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:540)
      7. com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:490)
      7 frames