Hi,
Has there been any update on the missing lob problem in the interim?
I don't think so, sorry. But you should test with the latest version;
1.3.167 is relatively old already.
Also, (as written earlier already) a simple, reproducible test case would
be great... ;-)
Regards,
Thomas
On Fri,
Hi, Thomas -
We are confronting a similar (possibly entirely different) issue described
in https://groups.google.com/d/msg/h2-database/awQR6dY5ZPY/74wcsGAWsCcJ We
have a workaround now and I have hopes that MVStore will completely
eliminate these two problems.
I'm not familiar with H2
We've fixed a number of bugs around LOB handling in the last couple of
months so updating to the latest version might be worth your while.
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To unsubscribe from this group and stop receiving emails
Hi,
I can't say much about the problem itself (yet).
But it's good that you can switch databases (Oracle, HSQLDB, H2,...), and
are not stuck with one storage backend.
Regards,
Thomas
On Thu, May 30, 2013 at 1:34 PM, Noel Grandin noelgran...@gmail.com wrote:
On 2013-05-30 12:58, Jason Pell
I am working on the same code that Eoin previously worked on. The fix for
breaking up the select query is still in the code, but recently we have
started getting the error again. The DB closed errors persist until the
process is restarted unfortunately.
Has there been any update on the
On 2013-05-30 00:34, Jason Pell wrote:
We finally got sick of this issue and migrated to HSQLDB for MVCC and
no more missing lob issues. We still use H2, but only for storing
configuration stuff that does not need to be updated concurrently.
It's a shame more attention has not been shown to
I can't argue with you there, and I can understand that this one is a
difficult problem, but from what I have read it's been around a while and
still is an open problem.
I find it strange that more attention has not been paid to it is all.
On Thursday, May 30, 2013 4:30:41 PM UTC+10, Noel
I'm using MVCC and the only problems I've come across appear to be with
LOBS (that's ok for me, don't really need them for my use case).
What I mean is that it may have been less work for you to try and fix
the H2 source (Seeing the issues seem to all be with LOBS) rather than
change to
On 2013-05-30 08:48, Ryan How wrote:
And it is getting lots of attention, the entire file store is being
re-written to accommodate for MVCC right from the start!, that is why
they haven't been giving attention to maintaining the current
experimental MVCC mode (Please correct me if I am
On 2013-05-30 08:42, Jason Pell wrote:
I find it strange that more attention has not been paid to it is all.
Mostly because most of us don't use it, we find the normal mode to be
pretty peachy.
Now, I have noticed that over the last year various people have bumped
into locking issues, some
Hi,
I have a sample of h2 failing when used with spring integration jdbc
message channel store that times out on lock. Adding mvcc fixes that
particular problem. I will get a minimum test case that demonstrates this.
The real issue is by default h2 locks entire table so only one thread can
On 2013-05-30 10:56, jasonmp...@gmail.com wrote:
The real issue is by default h2 locks entire table so only one thread
can perform dml stuff this makes it unsuitable for our situation. And
we actually only use h2 in test we use Oracle or sql server in production
H2 is pretty fast, even with
Fixing the H2 source is easier said than done, changing to HSQLDB was
actually a few hours of work, granted they were a painful few hours, but
when
you use JPA and Hibernate, switching DB's is relatively painless.
We are still using H2 for a lot of stuff, even in production, we just use
We are doing integration testing using HSQLDB, we still do full blown
integration test with oracle, but on developers PC's Oracle XE is way too
heavy, so we have a local build which uses HSQLDB. This does do stuff that
requires reasonable concurrency from the DB and tends to cause timeouts
On 2013-05-30 12:58, Jason Pell wrote:
The row level locking is what we really needed and thus because MVCC
is experimental
with H2, we had to go with another DB where the MVCC support works
well with CLOB.
I doubt that. I suspect that you were just hitting some unfortunate
deadlocks in
We finally got sick of this issue and migrated to HSQLDB for MVCC and no
more missing lob issues. We still use H2, but only for storing
configuration stuff that does not need to be updated concurrently. It's a
shame more attention has not been shown to this issue, because it was
certainly
On Friday, June 15, 2012 1:08:53 AM UTC-7, Noel Grandin wrote:
It works fine for some people, but others experience problems. The
bottom line is that we're just not sure. The people having problems have
never been able to produce us a decent test case, so it's kind of hard
to fix.
I
We tested a change last night which broke up the select * on the lob table
to select in batches of 1000 entries and it seems to have fixed the
Missing LOB error. There were no DB closed errors either. Because the
problem seems intermittent that's no guarantee that the issue has been
fixed but it
On 2012-06-15 09:54, Eoin Byrne wrote:
It looks like we will have to turn MVCC back on because we are now
hitting a large number of table lock timeouts but thats going to
reintroduce the DB file growth issue. I know this feature is
experimental but I guess my question is how experimental is
)
The host process lives on for a few hours and every access gets the DB
closed message.
There are a few other things worth mentioning - the host process uses
only a single connection so I guess the missing lob issue is causing
the connection to get closed or at least the session object to get
marked
On 2012-06-14 10:52, Eoin Byrne wrote:
Is there any guidance on what the max number of lobs I can bring back
per ResultSet? It it related to a cache size?
The number of CLOB / BLOB values that are cached on the server is now
the maximum of: 5 times the SERVER_RESULT_SET_FETCH_SIZE (which
and the connection
string we are using is:
jdbc:h2:tcp://host:port//file
path;AUTO_RECONNECT=TRUE;MVCC=TRUE;JMX=TRUE;LOCK_TIMEOUT=1;
Has anyone any idea how to fix the missing lob issue or what kind of
application behaviour might be causing the problem? This code is from
a very large project being
=1.3.167
And the SQL gives the same output: 167
I'll try it again without the reconect but it will take a day or so before
I'm able to get the results.
From what I know so far:
The database closed issue seems to be related to the missing lob issue,
I've never seen it without the misisng lob first
Hi,
Is there any other info you need?
Hm, a simple, reproducible test case would be great... ;-)
Regards,
Thomas
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To post to this group, send email to h2-database@googlegroups.com.
To unsubscribe
heh - tell me about it, having to wait 8 hours to see if a fix works can
make things difficult :)
On Thu, Jun 14, 2012 at 6:23 PM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
Is there any other info you need?
Hm, a simple, reproducible test case would be great... ;-)
Regards,
)
The host process lives on for a few hours and every access gets the DB
closed message.
There are a few other things worth mentioning - the host process uses
only a single connection so I guess the missing lob issue is causing
the connection to get closed or at least the session object to get
on for a few hours and every access gets the DB
closed message.
There are a few other things worth mentioning - the host process uses
only a single connection so I guess the missing lob issue is causing
the connection to get closed or at least the session object to get
marked as closed, I
Is it possible that turning MVCC off could solve the issue? It is possible
to use a read committed isolation level without MVCC?
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To view this discussion on the web visit
28 matches
Mail list logo
