OpenJPA
  1. OpenJPA
  2. OPENJPA-1367

H2 Database Engine does support cross join

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.1, 2.0.0-M1, 2.0.0-M2, 2.0.0-M3, 2.0.0-beta
    • Fix Version/s: 1.3.0, 2.0.0-beta2
    • Component/s: docs, jdbc, sql
    • Labels:
      None

      Description

      The documentation says that the H2 database does not support cross joins:

      http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/dbsupport_h2.html
      http://openjpa.apache.org/builds/2.0.0-M3/apache-openjpa-2.0.0-M3/docs/manual/main.html

      H2 does support cross join since a long time (I don't remember what version). See: http://www.h2database.com/html/grammar.html#table_expression (CROSS). A condition is not required for cross join.

      I think the documentation should be changed, and probably the H2Dictionary should be changed as well (crossJoinClause = "CROSS JOIN"; requiresConditionForCrossJoin = false.

      1. OPENJPA-1367.patch
        4 kB
        Prashant Bhat
      2. openjpa-h2-test-results.txt
        8 kB
        Prashant Bhat

        Activity

        Thomas Mueller created issue -
        Hide
        Prashant Bhat added a comment -

        I've run the test cases using H2 Database-1.2.127 with current trunk revision: r901901 Please refer to the attached test-results.txt file for more details.

        Descriptions for the changes in attached patch:
        1. H2Dictionary changes:
        a) as per this issue comment: crossJoinClause = "CROSS JOIN"; requiresConditionForCrossJoin = false;
        b) Return Types.BOOLEAN for Types.BIT in getPreferredType(type) because of warning message shown while running MappingTool. The message looked like this:
        4396 workflow-entities WARN [main] openjpa.jdbc.Schema - Existing column "ACTIVE" on table "OPENJPA.WORKFLOW_TASK_GROUP" is incompatible with the same column in the given schema definition. Existing column:
        Full Name: WORKFLOW_TASK_GROUP.ACTIVE
        Type: unknown(16)
        Size: 1
        Default: null
        Not Null: false
        Given column:
        Full Name: workflow_task_group.active
        Type: bit
        Size: 0
        Default: null
        Not Null: false

        c) H2 requires limit to be present for using offset. http://www.h2database.com/html/grammar.html#select

        2. Changes to sql-error-state-codes.xml : added missing error-codes (caused some test failures!)
        3. TestMultipleSchemaNames.java : Similar to Postgres, H2 requires schema to be created as as it does not create them automatically.

        4. And in the documentation: I've changed the comment 'H2 does not support cross joins' to 'None'
        But as the following test cases fail, may be it should be explained here. I'll leave it to someone with more knowledge about these failures.
        a) module openjpa-peristence-jdbc -> All the tests completed successfully, except for the error in following test:
        org.apache.openjpa.persistence.sequence.TestSequence => error in: testMultiThreadedNativeSequences
        b) module openjpa-peristence-locking Tests run: 185, Failures: 43, Errors: 0, Skipped: 0

        Hope this patch can be integrated into OpenJpa-2.0!

        Thanks,
        Prashant

        Show
        Prashant Bhat added a comment - I've run the test cases using H2 Database-1.2.127 with current trunk revision: r901901 Please refer to the attached test-results.txt file for more details. Descriptions for the changes in attached patch: 1. H2Dictionary changes: a) as per this issue comment: crossJoinClause = "CROSS JOIN"; requiresConditionForCrossJoin = false; b) Return Types.BOOLEAN for Types.BIT in getPreferredType(type) because of warning message shown while running MappingTool. The message looked like this: 4396 workflow-entities WARN [main] openjpa.jdbc.Schema - Existing column "ACTIVE" on table "OPENJPA.WORKFLOW_TASK_GROUP" is incompatible with the same column in the given schema definition. Existing column: Full Name: WORKFLOW_TASK_GROUP.ACTIVE Type: unknown(16) Size: 1 Default: null Not Null: false Given column: Full Name: workflow_task_group.active Type: bit Size: 0 Default: null Not Null: false c) H2 requires limit to be present for using offset. http://www.h2database.com/html/grammar.html#select 2. Changes to sql-error-state-codes.xml : added missing error-codes (caused some test failures!) 3. TestMultipleSchemaNames.java : Similar to Postgres, H2 requires schema to be created as as it does not create them automatically. 4. And in the documentation: I've changed the comment 'H2 does not support cross joins' to 'None' But as the following test cases fail, may be it should be explained here. I'll leave it to someone with more knowledge about these failures. a) module openjpa-peristence-jdbc -> All the tests completed successfully, except for the error in following test: org.apache.openjpa.persistence.sequence.TestSequence => error in: testMultiThreadedNativeSequences b) module openjpa-peristence-locking Tests run: 185, Failures: 43, Errors: 0, Skipped: 0 Hope this patch can be integrated into OpenJpa-2.0! Thanks, Prashant
        Prashant Bhat made changes -
        Field Original Value New Value
        Attachment OPENJPA-1367.patch [ 12431097 ]
        Attachment openjpa-h2-test-results.txt [ 12431098 ]
        Milosz Tylenda made changes -
        Assignee Milosz Tylenda [ milosz ]
        Hide
        Milosz Tylenda added a comment -

        Hi, Prashant,

        Thank you very much for your patch! I will look into it.

        Briefly looking, I have a question on the LIMIT clause. Do you know whether "LIMIT 0" means "return all rows" or "return no rows"? If "return no rows", we would need to issue "LIMIT big_constant" instead.

        Show
        Milosz Tylenda added a comment - Hi, Prashant, Thank you very much for your patch! I will look into it. Briefly looking, I have a question on the LIMIT clause. Do you know whether "LIMIT 0" means "return all rows" or "return no rows"? If "return no rows", we would need to issue "LIMIT big_constant" instead.
        Hide
        Prashant Bhat added a comment -

        Actually I tried it with H2, it returns 'all rows' for 'limit 0'. and Long.MAX_VALUE should also work. So, either of them should be fine.

        Thanks,
        Prashant

        Show
        Prashant Bhat added a comment - Actually I tried it with H2, it returns 'all rows' for 'limit 0'. and Long.MAX_VALUE should also work. So, either of them should be fine. Thanks, Prashant
        Hide
        Milosz Tylenda added a comment -

        Prashant, I have applied your patch into 2.0.x branch, with slight modifications:

        • Removed a few variable assignments in H2Dictionary since DBDictionary already assigns the same values to them.
        • Modified a bit SQL error codes file. A caveat here is the difference between SQL state and SQL error code. It is handled by DBDictionary.matchErrorState method which uses SQL states to determine exception type unless the method is overriden. I found some H2 source file [1] helpful here.

        As for org.apache.openjpa.persistence.sequence.TestSequence, it is failing because of a deadlock in INSERT statement. I believe this is because H2 uses table level locking and this test executes a lot of parallel inserts into two tables. I also ran the test with MVCC option turned on in H2 which is supposed to use row level locking but I ended up with OutOfMemoryError (although I only tried in-memory database). Anyway having only one test failing in openjpa-persistence-jdbc module is a very good result.

        Unfortunately I am currently not familiar with internals of openjpa-peristence-locking tests and do not have enough time to dig into them now. As you have noted in your attachment, the results are better with MVCC option turned on. I can only guess that the tests fail mainly due to different locking semantics in H2 than the tests assume.

        I am going to apply the patch also to the 1.3.x branch and then mark the issue resolved. If you would like to continue work on the mentioned failing tests, please open a new issue.

        Thomas, thank you for pointing the CROSS JOIN issue. The patch applied contains the fix.

        [1] http://kickjava.com/src/org/h2/message/Message.java.htm

        Show
        Milosz Tylenda added a comment - Prashant, I have applied your patch into 2.0.x branch, with slight modifications: Removed a few variable assignments in H2Dictionary since DBDictionary already assigns the same values to them. Modified a bit SQL error codes file. A caveat here is the difference between SQL state and SQL error code. It is handled by DBDictionary.matchErrorState method which uses SQL states to determine exception type unless the method is overriden. I found some H2 source file [1] helpful here. As for org.apache.openjpa.persistence.sequence.TestSequence, it is failing because of a deadlock in INSERT statement. I believe this is because H2 uses table level locking and this test executes a lot of parallel inserts into two tables. I also ran the test with MVCC option turned on in H2 which is supposed to use row level locking but I ended up with OutOfMemoryError (although I only tried in-memory database). Anyway having only one test failing in openjpa-persistence-jdbc module is a very good result. Unfortunately I am currently not familiar with internals of openjpa-peristence-locking tests and do not have enough time to dig into them now. As you have noted in your attachment, the results are better with MVCC option turned on. I can only guess that the tests fail mainly due to different locking semantics in H2 than the tests assume. I am going to apply the patch also to the 1.3.x branch and then mark the issue resolved. If you would like to continue work on the mentioned failing tests, please open a new issue. Thomas, thank you for pointing the CROSS JOIN issue. The patch applied contains the fix. [1] http://kickjava.com/src/org/h2/message/Message.java.htm
        Milosz Tylenda made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Milosz Tylenda made changes -
        Fix Version/s 2.0.0 [ 12314019 ]
        Hide
        Prashant Bhat added a comment - - edited

        Milosz Tylenda, thanks for reviewing and applying the patch.

        I've noticed an exception 'Connection not closed' being shown in database log (*.trace.db) for almost every test although the test passes!
        trace.db file grows upto 9.5mb after running full persistence-jdbc tests. Is it because the entity manager is not closed at the end of each test? Or is some other configuration missing for h2?
        for ex.: mvn -Ptest-h2 -Dtest=TestException test

        throws the following exception:
        [code]
        02-04 12:08:42 jdbc[13]: Connection not closed
        java.lang.Exception: Stack Trace
        at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:121)
        at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:94)
        at org.h2.Driver.connect(Driver.java:58)
        at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:38)
        at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:294)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1148)
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
        at org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:131)
        at org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:106)
        at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:91)
        at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:595)
        at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1489)
        at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:507)
        at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:432)
        at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:104)
        at org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68)
        at org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:83)
        at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:920)
        at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:911)
        at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:619)
        at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:188)
        at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:152)
        at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:200)
        at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:151)
        at org.apache.openjpa.persistence.exception.TestException.testIllegalArgumennExceptionOnInvalidNamedQuery(TestException.java:188)
        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:597)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        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:597)
        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        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:597)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
        [/code]

        Show
        Prashant Bhat added a comment - - edited Milosz Tylenda, thanks for reviewing and applying the patch. I've noticed an exception 'Connection not closed' being shown in database log (*.trace.db) for almost every test although the test passes! trace.db file grows upto 9.5mb after running full persistence-jdbc tests. Is it because the entity manager is not closed at the end of each test? Or is some other configuration missing for h2? for ex.: mvn -Ptest-h2 -Dtest=TestException test throws the following exception: [code] 02-04 12:08:42 jdbc [13] : Connection not closed java.lang.Exception: Stack Trace at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:121) at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:94) at org.h2.Driver.connect(Driver.java:58) at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:38) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:294) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1148) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) at org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:131) at org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:106) at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:91) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:595) at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1489) at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:507) at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:432) at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:104) at org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68) at org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:83) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:920) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:911) at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:619) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:188) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:152) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:200) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:151) at org.apache.openjpa.persistence.exception.TestException.testIllegalArgumennExceptionOnInvalidNamedQuery(TestException.java:188) 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:597) at junit.framework.TestCase.runTest(TestCase.java:154) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) 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:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) [/code]
        Milosz Tylenda made changes -
        Component/s jdbc [ 12311300 ]
        Component/s sql [ 12311310 ]
        Component/s jpa [ 12311304 ]
        Hide
        Milosz Tylenda added a comment -

        Prashant, most likely some (or even most of) connections are still open at the end of test but not because of not closing EntityManagers. The cause is rather a connection pool (Apache DPCP) being used by the test suite. I haven't seen the exceptions you mention, maybe because I did not enable trace log in H2.

        Looking at your stack trace, I would say you use H2 in kind of one-connection-only mode. Is this the case? I am not very familiar with H2.

        I don't have answer for your question on H2 configuration. I would try tweaking DBCP connection properties and H2 settings. If you have an IDE with OpenJPA source, you can also try running some test from there, without DBCP. Below I am including my settings for your reference:

        <profile>
        <id>test-h2-milosz</id>
        <properties>
        <test-custom>true</test-custom>
        <openjpa.custom.driverjar>/alt/jdbc/h2-1.1.118.jar</openjpa.custom.driverjar>
        <openjpa.custom.driverclass>org.h2.Driver</openjpa.custom.driverclass>
        <openjpa.custom.url>jdbc:h2:mem:oj;DB_CLOSE_DELAY=-1</openjpa.custom.url>
        <openjpa.custom.username>sa</openjpa.custom.username>
        <openjpa.custom.password></openjpa.custom.password>
        <dbcp.args>
        MaxActive=100,MaxIdle=10,MaxWait=10000,timeBetweenEvictionRunsMillis=2000,minEvictableIdleTimeMillis=1000
        </dbcp.args>
        </properties>
        </profile>

        Show
        Milosz Tylenda added a comment - Prashant, most likely some (or even most of) connections are still open at the end of test but not because of not closing EntityManagers. The cause is rather a connection pool (Apache DPCP) being used by the test suite. I haven't seen the exceptions you mention, maybe because I did not enable trace log in H2. Looking at your stack trace, I would say you use H2 in kind of one-connection-only mode. Is this the case? I am not very familiar with H2. I don't have answer for your question on H2 configuration. I would try tweaking DBCP connection properties and H2 settings. If you have an IDE with OpenJPA source, you can also try running some test from there, without DBCP. Below I am including my settings for your reference: <profile> <id>test-h2-milosz</id> <properties> <test-custom>true</test-custom> <openjpa.custom.driverjar>/alt/jdbc/h2-1.1.118.jar</openjpa.custom.driverjar> <openjpa.custom.driverclass>org.h2.Driver</openjpa.custom.driverclass> <openjpa.custom.url>jdbc:h2:mem:oj;DB_CLOSE_DELAY=-1</openjpa.custom.url> <openjpa.custom.username>sa</openjpa.custom.username> <openjpa.custom.password></openjpa.custom.password> <dbcp.args> MaxActive=100,MaxIdle=10,MaxWait=10000,timeBetweenEvictionRunsMillis=2000,minEvictableIdleTimeMillis=1000 </dbcp.args> </properties> </profile>
        Milosz Tylenda made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 1.3.0 [ 12313326 ]
        Resolution Fixed [ 1 ]
        Donald Woods made changes -
        Fix Version/s 2.0.0-beta2 [ 12314802 ]
        Fix Version/s 2.0.0 [ 12314019 ]
        Affects Version/s 2.0.0-beta [ 12314149 ]
        Affects Version/s 2.0.0-M3 [ 12314148 ]
        Affects Version/s 2.0.0-M2 [ 12313483 ]
        Donald Woods made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Milosz Tylenda
            Reporter:
            Thomas Mueller
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development