Hi

Please use a different subject in your message.

>> - The built-in JdbcConnectionPool is now about 70 times faster.
>> - More bugs in the server-less multi-connection mode have been fixed.
>
> Should the JdbcConnectionPool be used for server-less multi-connection
> mode?

You can, but it's not made specially for that. You can use it in all cases.

> Pre-110, I had a spike with H2 in my app using a "FakeDataSource" that
> in FakeDataSource.getConnection() just did:
>
>    public Connection getConnection() throws SQLException {
>        return 
> DriverManager.getConnection("jdbc:h2:mem:foo;DB_CLOSE_DELAY=-1");
>    }
>
> Which seemed to work fine. Thinking the pool might be faster, I just
> tried, with 110, using:
>
>    JdbcConnectionPool.create("jdbc:h2:mem:foo;DB_CLOSE_DELAY=-1", "", "");
>
> As my app's datasource.
>
> However, about halfway through my test suite, I'm now getting:
>
> Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table 
> primitives; SQL statement:
> DELETE FROM "primitives" [50200-110]
>        at org.h2.message.Message.getSQLException(Message.java:107)
>        at org.h2.message.Message.getSQLException(Message.java:118)
>        at org.h2.message.Message.getSQLException(Message.java:77)
>        at org.h2.table.TableData.doLock(TableData.java:435)
>        at org.h2.table.TableData.lock(TableData.java:374)
>        at org.h2.command.dml.Delete.update(Delete.java:51)
>        at org.h2.command.CommandContainer.update(CommandContainer.java:71)
>        at org.h2.command.Command.executeUpdate(Command.java:207)
>        at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:117)
>        at joist.jdbc.Jdbc.update(Jdbc.java:59)
>        ... 15 more
>
> Changing it back to the FakeDataSource/DriverManager.getConnection fixes
> the problem. Should I not bother with JdbcConnectionPool given I'm using
> an in-memory db? I was hoping for a bit of a speed up from it, but can't
> tell since the lock timeout fails the rest of the tests.

Did you commit all transactions and set autoCommit to true before
returning the connection to the pool? I don't know if the connection
pool should do that for you... I will probably have to change the
connection pool again, because the current behavior is probably not
correct.

Regards,
Thomas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/h2-database?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to