Hi Thomas,
setting the query cache to 0 solved the problem.
With a size of 1 the cache still consumed 70MB.
The largest statement is approximately 140KB long.
The statement is not a prepared statement.
The statement outer joins two tables containing approximately 2
rows/50 columns
Hi Noel,
It is, of course. I just figured that there might be some potential of
introducing more compatibility with other databases, if this is a
low-hanging fruit, implementation-wise.
Cheers
Lukas
2013/5/13 Noel Grandin noelgran...@gmail.com
The ALTER TABLE variant looks like it's more
Hi,
we are using EclipseLink 2.4.1 as ORM layer and H2 1.3.170 as database.
When we tried to update to the latest H2 version 1.3.171, we got a couple
of failing unit tests.
This is the query that is executed by one of our tests:
SELECT DISTINCT t1.ID AS a1, ...
FROM CATEGORYEJB t0,
This was fixed in SVN a little while ago, so it'll be in the next release.
Please test with the nightly build to confirm.
On 2013-05-13 10:29, Flo Schwarz wrote:
Hi,
we are using EclipseLink 2.4.1 as ORM layer and H2 1.3.170 as database.
When we tried to update to the latest H2 version
Somewhere you have code that is trying to read from a ResultSet after
the connection has been closed.
On 2013-05-13 14:56, davide.cavestro wrote:
Hi,
I've configured a H2 XA datasource to be orchestred by JBossTS.
Sometimes I get some failures complaining
/Caused by:
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
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
Thanks for the reply.
Most of the time I only use put and get, I think these methods will be
stable and I don't need to change my code very often.
I will try it.
Am Mittwoch, 8. Mai 2013 22:08:30 UTC+2 schrieb Thomas Mueller:
Hi,
I don't expect any big changes, but I still consider it
Dear Noel,
if the problem were so simple we wouldn't have spent time to write here.
We are talking about a piece of code that is iterating over a result set
and, from one iteration to the other, is failing because H2 says that the
connection is closed, while of course our code isn't closing it in
I'm not denigrating your code, I'm simply stating a fact
- switching to an in-memory database like H2 will accelerate things by
an order of magnitude and expose bugs that have long been lying hidden.
Happens to me all the time.
We don't have an internal transaction timeout.
I suggest you
On Monday, May 13, 2013 4:10:25 PM UTC+2, Noel Grandin wrote:
I'm not denigrating your code, I'm simply stating a fact
- switching to an in-memory database like H2 will accelerate things by
an order of magnitude and expose bugs that have long been lying hidden.
Happens to me all the time.
H2 is very easy to build.
http://h2database.com/html/build.html
--
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+unsubscr...@googlegroups.com.
To post
Hi,
Is it coming soon and/or is there anything available for testing?
No, I'm sorry, there are currently no plans to improve it. Patches would be
welcome however!
Regards,
Thomas
On Fri, May 10, 2013 at 5:41 AM, RJ 4ral...@gmail.com wrote:
Hi,
I am moving an H2 based project to Android,
Hi,
the statement is only 140 KB
Well, that's quite bit for a SQL statement. Still I wonder if the memory
usage is data or expressions. Could you get a full heap dump and check
which class uses how much memory?
Regards,
Thomas
On Mon, May 13, 2013 at 9:20 AM, christoff.schm...@finaris.de
Hi,
By the way, currently you need to call commit from time to time (not too
often if possible, for best performance). This is currently needed, but I
think in future versions there will be auto-commit from time to time by
default (a feature that can be disabled). This will still allow you to
Hi,
What you could do is: change the source code of H2 so that it remembers the
stack trace when closing the connection, and then throws this exception in
JdbcStatement.checkClosed (instead of throwing a generic connection
closed exception).
class JdbcConnection {
SQLException closePoint;
Sorry, I mentioned the incorrect version number, I am using *1.3.168*.
Earlier we also tried without MVCC but that didn't help.
Just for your information that the index which is creating the problem is
on a timestamp column if that can give you some clue about the problem.
We are very close
17 matches
Mail list logo
