JDBC 4.0

[steve.ebersole]

I have seen at least one other topic in reference to JDBC 4.0, but that did not answer my question.

In Hibernate I have need to call DatabaseMetaData#getSchema(String,String) which was a method added in JDBC 4.0 (Java 6).  However, that leads to an AbstractMethod exception for me:

java.lang.AbstractMethodError: org.h2.jdbc.JdbcDatabaseMetaData.getSchemas(Ljava/lang/String;Ljava/lang/String;)Ljava/sql/ResultSet;

I am currently using H2 version 1.2.145.  I had previously tried upgrading to 1.4.186 but ran into a lot of problems with MVCC support and had not yet had time to investigate that.

So my question is, what is the first release of H2 that supports JDBC 4.0?

[Thomas Mueller]

Hi,

I would probably try version 1.3.176 (2014-04-05), which is marked as the "last stable" version. 

The method DatabaseMetaData#getSchema(String,String) is there since about February 2011, but threw an exception back then ("unsupported"). In February 2013 (revision 4659) the method was correctly implemented ("Fix issue #438 JdbcDatabaseMetaData#getSchemas() no longer supported as of 1.3.169"). This was released in version 1.3.171 (2013-03-17).

> AbstractMethodError

Yes, with version 1.2.145 that's possible.

> ran into a lot of problems with MVCC support

How could we reproduce this ourselves?

Regards,

Thomas

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[steve.ebersole]

I would probably try version 1.3.176 (2014-04-05), which is marked as the "last stable" version. 

The method DatabaseMetaData#getSchema(String,String) is there since about February 2011, but threw an exception back then ("unsupported"). In February 2013 (revision 4659) the method was correctly implemented ("Fix issue #438 JdbcDatabaseMetaData#getSchemas() no longer supported as of 1.3.169"). This was released in version 1.3.171 (2013-03-17).

I ended up getting 1.4.186 to work.  I still have intermittent issues getting H2 to be able to properly compile stored procedures I pass it.  That was something I reported to you along time ago on this list.  But I get those intermittent issues in 1.3 as well as 1.4...  

 

> ran into a lot of problems with MVCC support

How could we reproduce this ourselves?

 

It is actually a known "limitation".  I saw an issue about it.  You do not support a combo of MVCC and queries with joins + for update.

[Steve Ebersole]

 

It is actually a known "limitation".  I saw an issue about it.  You do not support a combo of MVCC and queries with joins + for update.

One thing that really hurts, that maybe you have some thoughts on dealing with, is that once I removed MVCC from the connection URL in one place other tests (mainly other subprojects) that still use the connection URL with  MVCC start failing thinking I am trying to change the MVCC setting of an already existing database[1].  Really each can use its own database.  Do you have any thoughts/suggestions on making sure one database is closed and another is opened around testsuites for a project?

[1] Caused by: org.h2.jdbc.JdbcSQLException: Cannot change the setting "MVCC" when the database is already open; SQL statement:

[Noel Grandin]

On 2015-04-07 10:32 PM, Steve Ebersole wrote:
> One thing that really hurts, that maybe you have some thoughts on dealing with, is that once I removed MVCC from the
> connection URL in one place other tests (mainly other subprojects) that still use the connection URL with MVCC start
> failing thinking I am trying to change the MVCC setting of an already existing database[1]. Really each can use its own
> database. Do you have any thoughts/suggestions on making sure one database is closed and another is opened around
> testsuites for a project?

We run a deleteDb() command at the end of every test to make sure there is nothing left lying around to trip up the next
test.

[Steve Ebersole]

I have no idea what "deleteDb()"is.  Is it a method on some class?  A command I send via the connection? ??

--
You received this message because you are subscribed to a topic in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/h2-database/dQaB7-9yYG8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to h2-database+unsubscribe@googlegroups.com.

[Noel Grandin]

On 2015-04-08 02:31 PM, Steve Ebersole wrote:
> I have no idea what "deleteDb()"is. Is it a method on some class? A command I send via the connection? ??
>

It's a utility method in our test code. It deletes the files on disk that represent the H2 database.

[Thomas Mueller]

Hi,

What database URLs do you currently use?

Maybe we should add a way to auto-delete the database file if it is closed? This could be done in the file system abstraction, for example using the prefix "autoDelete:", so that a database URL would look like "jdbc:h2:autoDelete:./target/db/test" (using a relative path in this case, which should be OK for unit tests).

Regards,

Thomas

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscribe@googlegroups.com.

[Steve Ebersole]

We had originally used jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;MVCC=TRUE

I had to change that everywhere to instead use jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1

--
You received this message because you are subscribed to a topic in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/h2-database/dQaB7-9yYG8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to h2-database...@googlegroups.com.

[Thomas Mueller]

Hi,

Well, the "db_close_delay=-1" will ensure the database is kept even if you close the last connection.

Could you just use different database names? That should solve the problem:

 jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;MVCC=TRUE

 jdbc:h2:mem:db2;DB_CLOSE_DELAY=-1;MVCC=FALSE

Or with version 1.4.x:

 jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1

 jdbc:h2:mem:db2;DB_CLOSE_DELAY=-1;MVCC=FALSE

Maybe you can even get rid of the "db_close_delay".

Regards,

Thomas

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.

[Steve Ebersole]

We added db_close_delay because we have tests that open a Hibernate Session (connection), do some work, close that Session (thus closing that connection), open a new Session and try to do some work with the stuff done in the initial Session.  But H2 had dropped the database in between.

[Thomas Mueller]

Hi,

We added db_close_delay because we have tests that open a Hibernate Session (connection), do some work, close that Session (thus closing that connection), open a new Session and try to do some work with the stuff done in the initial Session.  But H2 had dropped the database in between.

Yes, I understand that. That's fine.

But if you want to enable MVCC in one case, and disable it in another case, then you need to use two different databases. The easiest way is to use different database names. That's why I wrote:

jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;MVCC=TRUE

jdbc:h2:mem:db2;DB_CLOSE_DELAY=-1;MVCC=FALSE

Please note "db1" in one case, and "db2" in the other case. There are other options, but that's probably the easiest one.

Regards,

Thomas