What version to pick for production

[Silvio]

Since 1.4 is still beta and we have a habit of not using beta versions in production we are using 1.3.176. But since that one is quite old already and 1.4 still has the PageStore inside I wonder if there halve been bug fixes or improvements in 1.4 that might warrant switching to 1.4+PageStore. Of course, that would only be an option if the beta status of 1.4 mainly concerns the MvStore related functionality and the PageStore part is and has always been quite stable.

Any thoughts?

TIA

Silvio

[Noel Grandin]

We use 1.4 in production with both PageStore and MVStore, both are pretty stable.

We currently find PageStore to be slightly more stable when running on some systems in the field where power outages are extremely common (i.e. more than once per day), but even there we are thinking of moving to MVStore with the latest 1.4 builds.

The only downside with MVStore is that there might be a binary format change at some point in the future, which will need need a full dump and restore to upgrade across.

​

[Silvio]

Thank you for the info. I am still very uncomfortable using something that is marked as beta in production. But this beta status has lasted for a long time already and it is unclear when an actual release version will be available. And in the meantime I have seen multiple remarks about things that have been improved in 1.4 wrt. the PageStore.

Personally I would have preferred a release status for 1.4 as soon as the software was reliable enough to warrant use in production, regardless of a possible format change. Why not call that 1.5, 1.6 aso. to mark such backward incompatibility?

[Dennis Wagelaar]

It's the same for us: we use H2 in production as well, as a client-side database that caches part of the server-side database for offline use. If there's ever an inquiry into the cause of a particularly painful data loss of offline recorded data, using a beta version of a database engine is enough to conclude the inquiry. We are currently looking at the following timeline:

- 2011: choice of database engine: HSQLDB is inactive since 2010, H2 is actively developed: we chose H2

- 2014: last stable release of H2

- 2015: HSQLDB development restarted; 2.x release series

- 2016: still no stable H2 release

We're currently using H2 1.3.168: Upgrading to 1.3.176 has resulted in several cases of database file corruption, so we never pushed that to production. As a result, we're currently stuck with 1.3.168.

Op maandag 6 juni 2016 10:26:57 UTC+2 schreef Silvio:

[Thomas Mueller Graf]

Hi,

What I could do is make H2 version 1.4.192 "non-beta" now. I didn't want to do that because for some use cases (according to Steve McLeod), performance was not great with versions up to and including 1.4.191, and I didn't know about 1.4.192. But now I have confirmation from Steve McLeod that performance improved almost to the PageStore level. Not quite as good, but relatively close. As for stability, I didn't see any major problems with version 1.4.191 and 1.4.192.

What is a bit unexpected is that the jar file of 1.4.192 is compiled with Java 7, which doesn't match the documentation. This is my mistake.

Or, probably easier, is to release version 1.4.193 soon, and mark that as stable.

Regards,

Thomas

--
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...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[Ryan How]

Stability seems good to me. I sometimes get MS SQL and MySQL database corruptions either from power outages or OOM. I think you've done an insanely awesome job putting H2 together Thomas. Other more "Mainstream" products seem to get more hype and attention, but I don't think that makes them better. They probably just are marketed better.

Ryan

[Nicolas Fortin (OrbisGIS)]

Hi,

I'm working on a critical fix caused by null values in geometries :

https://github.com/h2database/h2database/pull/267

Please give me some days before releasing a stable version of H2.

Thanks

Nicolas FORTIN

Développeur d’applications - AI
Laboratoire d’Acoustique Environnementale (LAE)
Ifsttar Nantes, Route de Bouaye, CS 4, 44344 Bouguenais Cedex

Activités du Laboratoire d’Acoustique Environnementale : www.lae.ifsttar.fr
Un logiciel open-source pour l’acoustique des salles : I-Simpa (i-simpa.ifsttar.fr)
Un logiciel open-source pour des études d’impact en milieu extérieur : NoiseM@p (noisemap.orbisgis.org)

[Dennis Wagelaar]

Thank you very much! A "stable" release is mostly about the commitment of the H2 team, claiming that the release of H2 is "ready for use". Of course there will still be bugs, just like in our own software, but they won't be known critical bugs that we "should have taken into account before upgrading".

I will wait for Nicolas to finish his fix, though ;-).

Kinds regards,

Dennis Wagelaar

--
You received this message because you are subscribed to a topic in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/h2-database/iVvN4xUxuXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to h2-database...@googlegroups.com.

[Nicolas Fortin (OrbisGIS)]

Hi,

The issue is fixed in the pull request. I've tried to run the whole h2 unit tests, there is some issues but not related to my changes (fr localizations and ports already used)

regards,

Nicolas FORTIN

Développeur d’applications - AI
Laboratoire d’Acoustique Environnementale (LAE)
Ifsttar Nantes, Route de Bouaye, CS 4, 44344 Bouguenais Cedex

Activités du Laboratoire d’Acoustique Environnementale : www.lae.ifsttar.fr
Un logiciel open-source pour l’acoustique des salles : I-Simpa (i-simpa.ifsttar.fr)
Un logiciel open-source pour des études d’impact en milieu extérieur : NoiseM@p (noisemap.orbisgis.org)

[Adrian A.]

> Or, probably easier, is to release version 1.4.193 soon, and mark that as stable.

+1


Allot of frameworks that use/embed H2 still ship with 1.3.x because of the missing "stable"/"final" label.


Thanks in advance,

Adrian.

[Paul Erdos]

If I can post my personal opinion as someone who uses H2 database since 4 or 5 years now the main problem with H2 database is the corruption of the database which I experienced quite frequently even if I was always able to recover data with the Recovery tool.
The reason I still use H2 and thus the real thing which makes H2 a winning choice for my requirements is:

* Embeddable java database which just works with no installation
* possibility to run it as an embedded server and share it between multiple clients on a network

the two things above but mainly the second are the real deal with this database.
As you might have realized I use the options AUTO_SERVER=TRUE;AUTO_RECONNECT=TRUE; to share the database on a network between several machines.

This thing very few databases can do and is what, in my opinion, makes H2 relevant today with so many databases out there.

If someone doesn't need the two characteristics above, there are hordes of alternative databases like MySQL or MariaDB.

Hope my point of view can be helpful

[Silvio]

That would be more than great! Thanks in advance.

[Christian MICHON]

I would tend to disagree that the mvstore performance is almost at the level of pagestore: please find below some ETL jobs benchmarks on ITIS taxonomy database. 

FWIW, we use 1.3.176 on production servers, especially in server mode. We even had one application running 24/7 for more than a year with 1.3.176 without any data corruption.

For ETL temporary jobs, 1.4.19x are stable enough.

        +------+------+

        | page | mvcc |

--------+------+------+

1.3.168 |  80s |  N/A |

        |  80s |  N/A |

--------+------+------+

1.3.176 |  80s |  N/A |

        |  80s |  N/A |

--------+------+------+

1.4.191 |  77s | 102s |

        |  79s |  97s |

--------+------+------+

1.4.192 |  77s |  94s |

        |  76s |  99s |

--------+------+------+

[Silvio]

Ok. So mvstore is slower than pagestore in your scenario. I do not see that as a reason not to release. Ps speed has improved and if deemed stable I could go with that. And still have mvs as an alternative. The mvcc support might give us better performance under high concurrency scenarios.

[Dennis Wagelaar]

Hi Nicolas,

I've seen that your pull request is merged by now, and the master build is passing. Any chance a new 1.4.193 stable release can be built?

Kind regards,

Dennis Wagelaar

Op donderdag 9 juni 2016 10:07:20 UTC+2 schreef Nicolas Fortin (OrbisGIS):

[Petr Holík]

Hello,

any progress or timeline in releasing new(non Beta) version? We are facing some bugs in 1.3.* version. I it is not(for us) politically possible to use BETA in production we are going to have 100+ installations. (We are using still 1.3. with bugs workarounds :( )

Kind Regard Petr Holik

Dne pondělí 12. září 2016 10:35:46 UTC+2 Dennis Wagelaar napsal(a):

[Vitali]

We are using successfully  H2 1.4.x in production for almost 2 years in a big organization with 300 of users.  It's an embedded database behind GIS desktop system which is a main tool these 300 users are using daily. So, very business critical case :) Data (spatial data) is taken from central database (Postgre) and delivered to H2 where all kind of CRUD operations are performed.  Changes are collected and synchronized back to central database.

We always compile H2 from code with minor local changes optimizing the performance for certain SQL scenarios (probably some improvements are worth to contribute to master branch). PageStore mechanism is used. So far the biggest problem was the performance  and stability of BLOB/CLOB types. Since we got rid of them towards VARBINARY/VARCHAR types  the number of corrupted database cases dropped to almost 0. Actually it was mistake to use BLOB in datamodel design from the beginning, once I have learned better H2 internals an understanding that BLOB is not needed in our case solved the majority of database corruption cases from users.

There is so much to do still in H2, but it's great  Java product, thanks to developers!

P.S. Our optimizations concerned nested selects like  .... WHERE FK_COLUMN IN (SELECT... ) . Often when index exists for FK_COLUMN, parent table contains 200000 records and nested SELECT retrieves thousands of values implementation is not optimal; I try to write soon about this case with a patch suggested.

[Noel Grandin]

On 28 September 2016 at 17:02, Vitali <vit...@gmail.com> wrote:

P.S. Our optimizations concerned nested selects like  .... WHERE FK_COLUMN IN (SELECT... ) . Often when index exists for FK_COLUMN, parent table contains 200000 records and nested SELECT retrieves thousands of values implementation is not optimal; I try to write soon about this case with a patch suggested.

Would be good to see that patch, cool!