Hi all and sorry for cross-posting.
I'd like to propose upgrading the version of h2database in the trunk poms (both geoserver and geotools) to a newer version than the one currently used.
Situation is we've inadvertently been shipping geoserver with two h2 jars, h2-1.1.104.jar and h2-1.1.119.jar. The former used by geotools and geoserver, the later carried over as a transitive dependency from geowebcache.
I just discovered the problem while updating geoserver trunk to point to geowebcache snapshot and got a compile error, since gwc now uses some h2 connection pooling with some speed up benefits.
Having talked to Andrea and Arne, we've seen that the h2 database format doesn't change between those two versions, so, provided y update the poms on both trunks to use 1.1.119 instead of 1.1.104 and the build doesn't break, can I commit the version upgrade? any concern?
TIA,
Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan ha scritto:
Hi all and sorry for cross-posting.
I'd like to propose upgrading the version of h2database in the trunk poms (both geoserver and geotools) to a newer version than the one currently used.
Situation is we've inadvertently been shipping geoserver with two h2 jars, h2-1.1.104.jar and h2-1.1.119.jar. The former used by geotools and geoserver, the later carried over as a transitive dependency from geowebcache.
I just discovered the problem while updating geoserver trunk to point to geowebcache snapshot and got a compile error, since gwc now uses some h2 connection pooling with some speed up benefits.
Having talked to Andrea and Arne, we've seen that the h2 database format doesn't change between those two versions, so, provided y update the poms on both trunks to use 1.1.119 instead of 1.1.104 and the build doesn't break, can I commit the version upgrade? any concern?
As you said, it looks like 119 and 104 share the same disk format, so
if there is no regression in the build I don't see a problem with the
upgrade
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
+1
I have never actually had any issue with upgrading H2 and supporting databases created with older versions. Thomas seems pretty good about backward compatibility.
Indeed an upgrade works well for me. I want to start doing some h2 benchmarks with H2 and would like to work with the latest and greatest.
-Justin
On 10-06-22 2:14 AM, Gabriel Roldan wrote:
Hi all and sorry for cross-posting.
I'd like to propose upgrading the version of h2database in the trunk
poms (both geoserver and geotools) to a newer version than the one
currently used.
Situation is we've inadvertently been shipping geoserver with two h2
jars, h2-1.1.104.jar and h2-1.1.119.jar. The former used by geotools and
geoserver, the later carried over as a transitive dependency from
geowebcache.
I just discovered the problem while updating geoserver trunk to point to
geowebcache snapshot and got a compile error, since gwc now uses some h2
connection pooling with some speed up benefits.
Having talked to Andrea and Arne, we've seen that the h2 database format
doesn't change between those two versions, so, provided y update the
poms on both trunks to use 1.1.119 instead of 1.1.104 and the build
doesn't break, can I commit the version upgrade? any concern?
TIA,
Gabriel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
+1
I have never actually had any issue with upgrading H2 and supporting databases created with older versions. Thomas seems pretty good about backward compatibility.
Indeed an upgrade works well for me. I want to start doing some h2 benchmarks with H2 and would like to work with the latest and greatest.
The latest version changed the storage format, so once a data directory
is converted to use it (either because of superoverlays or gwc
metastore) you cannot go back.
I'm interested with experimentation of newer versions as well, but
it's probably better to do that on trunk only.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 6/22/10 4:38 PM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
+1
I have never actually had any issue with upgrading H2 and supporting
databases created with older versions. Thomas seems pretty good about
backward compatibility.
Indeed an upgrade works well for me. I want to start doing some h2
benchmarks with H2 and would like to work with the latest and greatest.
The latest version changed the storage format, so once a data directory
is converted to use it (either because of superoverlays or gwc
metastore) you cannot go back.
I'm interested with experimentation of newer versions as well, but
it's probably better to do that on trunk only.
Cheers
Andrea
Just to enumerate the options:
GeoServer 2.0.x : Stay at 104 or move to 119. The two are compatible both ways.
GeoServer 2.1.x : Stay at 104, move to 119 (minor improvements), or move to the 1.2 series of H2
The 1.2 series creates new databases in the "page store" format, which the older version cannot read. But existing databases will be kept in the old format, so in most cases you would be able to test GS 2.1.x and revert, even if you forgot to backup your data directory.
-Arne
Arne Kepp ha scritto:
The 1.2 series creates new databases in the "page store" format, which the older version cannot read. But existing databases will be kept in the old format, so in most cases you would be able to test GS 2.1.x and revert, even if you forgot to backup your data directory.
I guess it's something we have to double check. In the changelog of 1.2.129 there is this statement:
* Converting an old (non-page store) database is no longer supported using this version.
* Disabling the page store is no longer supported. The old storage mechanism has been removed, shrinking the jar file size by almost 10%.
The current version is 1.2.137
Btw, out of curiosity, HSQL db finally released version 2.0. No idea
of how it compares to H2 though:
http://sourceforge.net/projects/hsqldb/
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Understood, yet for the time being I'd like to limit to:
- No version changes in 2.0.x
- Upgrade trunk to 1.1.119
Rationale being I'm not trying to experiment with newer versions but to fix the version clash without having to get rid of the performance boost connection pooling gives to GWC.
Deal?
Gabriel
On 6/22/10 11:52 AM, Andrea Aime wrote:
Arne Kepp ha scritto:
The 1.2 series creates new databases in the "page store" format, which
the older version cannot read. But existing databases will be kept in
the old format, so in most cases you would be able to test GS 2.1.x and
revert, even if you forgot to backup your data directory.
I guess it's something we have to double check. In the changelog of
1.2.129 there is this statement:
* Converting an old (non-page store) database is no longer supported
using this version.
* Disabling the page store is no longer supported. The old storage
mechanism has been removed, shrinking the jar file size by almost 10%.
The current version is 1.2.137
Btw, out of curiosity, HSQL db finally released version 2.0. No idea
of how it compares to H2 though:
http://sourceforge.net/projects/hsqldb/
Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan ha scritto:
Understood, yet for the time being I'd like to limit to:
- No version changes in 2.0.x
- Upgrade trunk to 1.1.119
Rationale being I'm not trying to experiment with newer versions but to fix the version clash without having to get rid of the performance boost connection pooling gives to GWC.
Deal?
For the short term, sure.
For the mid term we have an interest in trying out a pumped up
version of the H2 datastore for the FOSS4G benchmarking, if
using the latest and greatest gives an appreciable speedup
there will be interest in upgrading further.
But that won't happen today
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 10-06-22 10:40 AM, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Understood, yet for the time being I'd like to limit to:
- No version changes in 2.0.x
- Upgrade trunk to 1.1.119
Rationale being I'm not trying to experiment with newer versions but to
fix the version clash without having to get rid of the performance boost
connection pooling gives to GWC.
Deal?
For the short term, sure.
For the mid term we have an interest in trying out a pumped up
version of the H2 datastore for the FOSS4G benchmarking, if
using the latest and greatest gives an appreciable speedup
there will be interest in upgrading further.
But that won't happen today
As a quick aside I just ran some quick benchmarks against a 1.1.x and the latest 1.2.x and it actually got significantly slower... that said that was no tweaking on my side so still worth some investigation.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
As a quick aside I just ran some quick benchmarks against a 1.1.x and
the latest 1.2.x and it actually got significantly slower... that said
that was no tweaking on my side so still worth some investigation.
interesting. Is that happening even using a connection pool?
It is a single connection firing off a bunch of requests simulating a bunch of wms requests in series.
Concurrency is a whole different ball of wax with h2 afaik. There are currently two modes which offer concurrent connections, MVCC and MULTI_THREADED. I am also interested in seeing how each performs until load.
On 10-06-22 3:02 PM, Gabriel Roldan wrote:
As a quick aside I just ran some quick benchmarks against a 1.1.x and
the latest 1.2.x and it actually got significantly slower... that said
that was no tweaking on my side so still worth some investigation.
interesting. Is that happening even using a connection pool?
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.