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 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;
c
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,
> 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, wrote:
> Hi Thomas,
>
>
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 And
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
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
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 star
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 i
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
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 som
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 Coor
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: org.h2.jdbc.JdbcSQLExcep
You're also running quite an old version of H2, updating to the latest
version would probably help.
I would also suggest running without MVCC, it's still a little rough
around the edges.
On 2013-05-13 14:47, Sanjeev Gour wrote:
I am getting the following error when running a clean up routin
Hi,
I've configured a H2 XA datasource to be orchestred by JBossTS.
Sometimes I get some failures complaining
/Caused by: org.h2.jdbc.JdbcSQLException: The object is already closed
[90007-169]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get
I am getting the following error when running a clean up routine on some of
the tables. I am using version 1.3.162. The JDBC url is configured with
the following options-
CACHE_TYPE=LRU;PAGE_SIZE=16384;MVCC=TRUE;DB_CLOSE_DELAY=-1
Also tried with ";optimize_update=false" to no avail. This typic
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 1.3.171
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, TERMEJB_CAT
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
> The ALTER TABLE variant looks like it's more generally useful than the
The ALTER TABLE variant looks like it's more generally useful than the
TRUNCATE version.
On 2013-05-10 12:57, Lukas Eder wrote:
Hello,
This is a minor feature request: Add support for the RESTART IDENTITY
/ CONTINUE IDENTITY options that can be passed to a TRUNCATE statement
in some database
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 (Oracle's
21 matches
Mail list logo
