Yeah, running things with a faster database will often expose timing
bugs that slower databases will hide for you.
It's still a bug in your code.
On 2013-05-13 15:29, davide.cavestro wrote:
Generically it is the more likely cause, but the same legacy code was written
and battle proven using some DBMS like PostgreSQL, Oracle and SQLServer with
the same Transaction Manager.
They all work fine with some adaptations, i.e. for SQL server we had to
configure the server-side Transaction Coordinator in order to avoid
transaction expiring.
I /simply added a new scenario/ where the source database is first copied
into a H2 one, so the pre-existing code now queries a (faster) embedded H2
instead of one of the previous mentioned remote dbms.
Also the tests on my local machine (with a reduced data set) never failed.
The failures compare on a test environment with a huge data set. That makes
me suspect for a transaction timeout problem.
Noel Grandin wrote
Somewhere you have code that is trying to read from a ResultSet after
the connection has been closed.
--
View this message in context:
http://h2-database.66688.n3.nabble.com/JdbcXAConnection-and-transaction-timeout-The-object-is-already-closed-tp4026399p4026402.html
Sent from the H2 Database mailing list archive at Nabble.com.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
