Great, thanks to Thomas' suggestion, I have implemented a fix for this.
On 2013-08-12 19:18, Thomas Mueller wrote:
Hi,
There is Database.getModificationMetaId(), which should return a
different value whenever there was a change in the metadata. Maybe
this could be used to ensure the cache
Here's another example of ArrayIndexOutOfBoundsException at
org.h2.index.PageDataLeaf.getRowAt: this happened on 1.3.168. The most
recent fix i found in changelog about this kind of error was 1.3.166, so
probably there's still something wrong since then, or have there been fixes
related to
On 2013-08-13 10:05, Dieter Cailliau wrote:
Here's another example of ArrayIndexOutOfBoundsException at
org.h2.index.PageDataLeaf.getRowAt: this happened on 1.3.168. The most
recent fix i found in changelog about this kind of error was 1.3.166,
so probably there's still something wrong
Excellent news - I'll look forward to the next version!
Cheers,
Ian.
On Tuesday, August 13, 2013 7:54:44 AM UTC+1, Noel Grandin wrote:
Great, thanks to Thomas' suggestion, I have implemented a fix for this.
--
You received this message because you are subscribed to the Google Groups
Awesome, thank you very much!
Patch applied with some tweaks.
On 2013-08-07 16:35, davide.cavestro wrote:
Ok, so here you are the revised patch.txt
http://h2-database.66688.n3.nabble.com/file/n4027076/patch.txt .
I've added some dedicated tests... they seem to pass, but if I connect using
h2
Hmmm, sorry, I don't have a quick fix for this.
It appears that the problem is not so much with getCharacterStream() as
it is with setCharacterStream().
If you could make your ORM use the setString() calls, the shutdown, and
in fact performance as a whole should improve.
On 2013-08-12
I've tried replacing setCharacterStream() with setString() but the db size
still continues to increase. Is there any way to get an idea of actual
fragmentation of internal data-structures?
Now it's time to try reproducing the issue with a test case: today I'm
feeling lucky :-)
Noel Grandin
Figured it out, it was my mistake.
On Thursday, August 8, 2013 11:00:24 PM UTC-5, austi...@gmail.com wrote:
I'm getting this
Caused by: org.h2.jdbc.JdbcSQLException: Table ACCOUNT not found; SQL
statement:
The table is there and database connection is active
Here is the url
I didn't measure it, but it was certainly lower. I'll give you more data
asap.
Noel Grandin wrote
On Tue, Aug 13, 2013 at 5:56 PM, davide.cavestro
lt;
davide.cavestro@
gt; wrote:
I've tried replacing setCharacterStream() with setString() but the db
size
still continues to increase. Is
Hi,
How large is the database exactly, and how does it grow exactly? Are you
completely sure it doesn't stop growing? If yes, could you kill the process
while the database is about 10 times as big as it should be, and then run
the recovery tool, and post the statistics part of the the output? And
Hi,
This should be fixed now. In the trunk currently, tomorrow it should be in
the Latest Automated Build (not
released)http://www.h2database.com/automated/h2-latest.jar
.
Regards,
Thomas
On Wed, May 29, 2013 at 7:36 PM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
Yes, it's a
I'll be more precise tomorrow, as at the moment I don't have access to the
test environment.
The massive data import is the first stage a a multi-step ETL process. It
collects data from an Oracle DB available on the LAN populating a local H2
db.
That premised, after the first import the H2
I am having multiple threads processing the data and querying against H2
database each thread might query h2 2,000,000 times.
I am thinking if each thread has it own H2 connection will it improve the
performance Vs having single connection for all threads?
I am thinking of using the connection
Sounds like you're on the right path. It's usually good practice to have
a connection per thread. A H2 connection is thread safe, but I don't
think that is the case for all DBs. But anyway, a connection per thread
is better, because then if you turn on multithreaded mode for H2 you
will get
14 matches
Mail list logo
