Re: [h2] Proliferation of undroppable SEQUENCES
I don't think there is much that you can do short of doing a SCRIPT and RUNSCRIPT cycle. You don't perhaps create temporary tables somewhere in your app? That's the only thing I can think of that might lead to a situation with that many sequences. Doing a backup to script and then grepping over that script is the easiest way to figure out if they are legitimate or not. I would suggest using compression to keep the script size reasonable. Something like SCRIPT TO temp.gz COMPRESSION GZIP And then you can use gunzip | grep SEQ_001 to search through it. On 2013-09-29 20:55, JND wrote: Hi, Does this ring a bell for anyone... #1. I have a database with about 100 tables. When I open the H2 Web console (port 8082) it exhibits excessive memory consumption at tree.js:82, to the point that the browser will consume all host memory. #2. While investigating this, I noticed that JavaScript is rendering the Sequences tree. Then I noticed that there are thousands upon thousands of sequences being listed. If I SCRIPT NODATA, all of the sequences are shown with CREATE SEQUENCES yet only 15 are associated with table columns in the CREATE TABLE DDLs. The other thousands also look very repetitive (most have a current value of 33 or 64). #3. These orphaned sequences cannot be dropped (“belongs to table”). I am running H2 1.3.173, but I guess these could be buggy sequences from a prior version. I’ve tried to create various test cases but cannot create more undroppable sequences in 1.3.173. I could try reproducing it in earlier versions but I don’t know which version(s) were affected or which test case(s) will reproduce it. My questions are: • How can I figure out if these sequences are “legitimate”? Currently I assume none of them will be needed for database integrity. • Is it possible this was caused by an H2 bug that’s fixed in .173, and kind of SQL could trigger it? • Assuming these sequences are bogus, what is the most efficient way of deleting them? I have a 20 GB production database that has about 146500 of these... J -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
[h2] Re: unable to write: the database is read only after system crash
I'm using h2-1.3.168 in jboss 7.2.0.Final on a Win7. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] unable to write: the database is read only after system crash
What exactly does the trace file say the problem is?
Also, this DB is working for me on the latest version.
Which may mean that the problem has been fixed, but might also just be
that something in your local environment, which is different to me, is
triggering the problem.
On 2013-09-30 10:40, Dieter Cailliau wrote:
Using
jdbc:h2:${jboss.server.data.dir:/tmp}/bms;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=${com.x.ds.bms.lock.timeout.ms:5000}
h2 goes to readonly-mode on the attached database.
It may have to do with recovery, since we get into this situation
(sometimes) by unpowering the machine (no clean shutdown).
It's not clear to me if this is intended behaviour (for a kind of db
corruption h2 was unable to fix on the fly) or erroneous (h2 should
have recovered on the fly, but there a h2 bug causing it to go into a
kind of safety readonly mode).
--
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 to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] unable to write: the database is read only after system crash
Every insert gives this in bms.trace.db org.h2.jdbc.JdbcSQLException: The database is read only; SQL statement: insert into Element (lastSeen, sources, name, options, tupple, host_string, assets2, DTYPE, string) values (?, ?, ?, ?, ?, ?, ?, 'DeviceCapabilityService', ?) [90097-168]^M at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)^M at org.h2.message.DbException.get(DbException.java:169)^M at org.h2.message.DbException.get(DbException.java:146)^M at org.h2.message.DbException.get(DbException.java:135)^M at org.h2.engine.Database.checkWritingAllowed(Database.java:1702)^M at org.h2.table.Table.checkWritingAllowed(Table.java:1060)^M at org.h2.engine.User.hasRight(User.java:111)^M at org.h2.engine.User.checkRight(User.java:97)^M at org.h2.command.dml.Insert.insertRows(Insert.java:93)^M at org.h2.command.dml.Insert.update(Insert.java:84)^M at org.h2.command.CommandContainer.update(CommandContainer.java:75)^M at org.h2.command.Command.executeUpdate(Command.java:230)^M at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:156)^M at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:142)^M at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)^M at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:125)^M at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:58)^M at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3058)^M at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3499)^M at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88)^M at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)^M at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)^M at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275)^M at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:328)^M at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)^M at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1212)^M at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:996)^M at org.jboss.as.jpa.container.AbstractEntityManager.flush(AbstractEntityManager.java:439)^M at ...my code Note that the problem started off on a win7, next i copied the bms.h2.db file to my ubuntu laptop, restart my app, and i get stuck the same way. The file permissions on linux are set to allow everyone to read/write. The file permissions on Win7 were also such that the SYSTEM user can do anything. So i guess it must be something inside the file. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
[h2] Stall using MVCC
Hi all, My application is stalling when using MVCC. I'm using the 1.3.173 version embedded in another application. I was able to reproduce the exact same behaviour with 1.3.164 but analysing the thread dump using that version it seemed to me that it was a deadlock. With the most recent version, it doesn't look like it. You can find a thread dump at the end of the post. I'm just trying to understand if this might be a bug or not in order to open up a bug. The statement is being submitted with autocommit turned off. *The table in question has the following schema:* CREATE TABLE ABC_APP_FIELD (CREATEDAT BIGINT, CREATEDBY INTEGER, UPDATEDAT BIGINT, UPDATEDBY INTEGER, APP_ID INTEGER NOT NULL, SFL_ID INTEGER AUTO_INCREMENT NOT NULL, SFL_TYPE VARCHAR(256), SCH_ID INTEGER, SFL_NAME VARCHAR(256) NOT NULL, SFL_DESC VARCHAR(256), SFL_IS_DIMENSION BOOLEAN, SFL_IS_TIMESTAMP BOOLEAN, FLD_ORDER INTEGER NOT NULL, FLD_PARENT INTEGER, FLD_NULLABLE BOOLEAN DEFAULT TRUE, FLD_STORE BOOLEAN DEFAULT TRUE, DIM_ID INTEGER) *The query being blocked is the following:* UPDATE ABC_APP_FIELD SET DIM_ID = 34 WHERE (SFL_ID) IN (216, 323, 329) AND APP_ID = 3 AND SFL_IS_DIMENSION = TRUE Anyone might know what can be wrong with this? Thanks in advance, Best regards, Rui -- *The thread dump:* jetty-246 prio=10 tid=0x7fb274198800 nid=0x6836 runnable [0x7fb1f9ad5000] java.lang.Thread.State: RUNNABLE at org.h2.index.TreeCursor.next(TreeCursor.java:82) at org.h2.index.TreeCursor.next(TreeCursor.java:50) at org.h2.index.MultiVersionIndex.removeIfExists(MultiVersionIndex.java:165) at org.h2.index.MultiVersionIndex.add(MultiVersionIndex.java:53) - locked 0xe2dc40d0 (a org.h2.engine.Database) at org.h2.table.RegularTable.addRow(RegularTable.java:125) at org.h2.command.dml.Insert.insertRows(Insert.java:127) at org.h2.command.dml.Insert.update(Insert.java:86) at org.h2.command.CommandContainer.update(CommandContainer.java:79) at org.h2.command.Command.executeUpdate(Command.java:235) - locked 0xe2dc40d0 (a org.h2.engine.Database) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154) - locked 0xe69e53c0 (a org.h2.engine.Session) at org.h2.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:1152) at com.abc.commons.sql.abstraction.engine.DatabaseEngineImpl.flush(DatabaseEngineImpl.java:596) - locked 0xe635f740 (a com.abc.commons.sql.abstraction.engine.impl.H2Engine) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$AddMappingsAction.apply(AppDimensionManagerImpl.java:377) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$1.access(AppDimensionManagerImpl.java:94) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$1.access(AppDimensionManagerImpl.java:71) at com.abc.def.web.api.commons.db.AbstractDbFun.call(AbstractDbFun.java:27) at com.abc.def.service.apps.manager.AppDimensionManagerImpl.doCreate(AppDimensionManagerImpl.java:71) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$$EnhancerByGuice$$df4a5902.CGLIB$doCreate$1(generated) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$$EnhancerByGuice$$df4a5902$$FastClassByGuice$$2f361d07.invoke(generated) at com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228) at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72) at com.abc.def.service.security.guice.EnforcePermissionsInterceptor.invoke(EnforcePermissionsInterceptor.java:53) at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72) at com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:52) at com.abc.def.service.apps.manager.AppDimensionManagerImpl$$EnhancerByGuice$$df4a5902.doCreate(generated) at com.abc.def.service.apps.manager.AppDimensionManagerImpl.doCreate(AppDimensionManagerImpl.java:62) at com.abc.def.service.apps.manager.CachingModelManager.create(CachingModelManager.java:90) at com.abc.def.service.apps.manager.OwnableModelManager.create(OwnableModelManager.java:59) at com.abc.def.service.apps.manager.OwnableModelManager.create(OwnableModelManager.java:49) at com.abc.def.service.apps.manager.AppAdminImpl$7.access(AppAdminImpl.java:1571) at com.abc.def.service.apps.manager.AppAdminImpl$7.access(AppAdminImpl.java:1532) at com.abc.def.web.api.commons.db.AbstractDbFun.call(AbstractDbFun.java:27) at com.abc.def.service.apps.manager.AppAdminImpl.importAppModel(AppAdminImpl.java:1532) at com.abc.def.service.apps.manager.AppAdminImpl$6.access(AppAdminImpl.java:1502) at com.abc.def.service.apps.manager.AppAdminImpl$6.access(AppAdminImpl.java:1491) at com.abc.def.web.api.commons.db.AbstractDbFun.call(AbstractDbFun.java:27) at com.abc.def.service.apps.manager.AppAdminImpl.importApp(AppAdminImpl.java:1491) at
Re: [h2] Stall using MVCC
MVCC has various issues. Some people use it successfully, for others it doesn't work so well. The basic advice, for now, is don't use it if it causes you problems. We're not going to work on fixing any bugs in MVCC itself because Thomas is working on a replacement engine which does MVCC more naturally than our current engine. On 2013-09-30 12:17, Rui Vilão wrote: My application is stalling when using MVCC. I'm using the 1.3.173 version embedded in another application. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] unable to write: the database is read only after system crash
Hi
I'm sorry, at this I've reached the limit of my knowledge of that area
of the engine.
Hopefully Thomas will chime in.
Is it indeed a problem in database recovery.
I can tell is that it the DB is being set readonly by the following
logic in PageStore.recover()
if (log.getInDoubtTransactions().size() == 0) {
log.recoverEnd();
int firstUncommittedSection = getFirstUncommittedSection();
log.removeUntil(firstUncommittedSection);
} else {
setReadOnly = true;
}
But what exactly that piece of logic is trying to achieve I do not know.
Regards, Noel.
On 2013-09-30 13:28, Dieter Cailliau wrote:
insert into Element (lastSeen, sources, name, options, tupple,
host_string, assets2, DTYPE, string) values (?, ?, ?, ?, ?, ?, ?,
'DeviceCapabilityService', ?)
--
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 to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] Stall using MVCC
Hi, Thank you for the quick reply. Do you have a date for that release already? Thanks, Rui On Mon, Sep 30, 2013 at 12:46 PM, Noel Grandin noelgran...@gmail.com wrote: MVCC has various issues. Some people use it successfully, for others it doesn't work so well. The basic advice, for now, is don't use it if it causes you problems. We're not going to work on fixing any bugs in MVCC itself because Thomas is working on a replacement engine which does MVCC more naturally than our current engine. On 2013-09-30 12:17, Rui Vilão wrote: My application is stalling when using MVCC. I'm using the 1.3.173 version embedded in another application. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] Stall using MVCC
Thomas is working on it in his spare time, so pretty much sometime in the next year or so On 2013-09-30 13:56, Rui Vilão wrote: Hi, Thank you for the quick reply. Do you have a date for that release already? Thanks, Rui On Mon, Sep 30, 2013 at 12:46 PM, Noel Grandin noelgran...@gmail.com mailto:noelgran...@gmail.com wrote: MVCC has various issues. Some people use it successfully, for others it doesn't work so well. The basic advice, for now, is don't use it if it causes you problems. We're not going to work on fixing any bugs in MVCC itself because Thomas is working on a replacement engine which does MVCC more naturally than our current engine. On 2013-09-30 12:17, Rui Vilão wrote: My application is stalling when using MVCC. I'm using the 1.3.173 version embedded in another application. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] Stall using MVCC
Right thanks. Rui On Mon, Sep 30, 2013 at 12:57 PM, Noel Grandin noelgran...@gmail.com wrote: Thomas is working on it in his spare time, so pretty much sometime in the next year or so On 2013-09-30 13:56, Rui Vilão wrote: Hi, Thank you for the quick reply. Do you have a date for that release already? Thanks, Rui On Mon, Sep 30, 2013 at 12:46 PM, Noel Grandin noelgran...@gmail.com mailto:noelgran...@gmail.com wrote: MVCC has various issues. Some people use it successfully, for others it doesn't work so well. The basic advice, for now, is don't use it if it causes you problems. We're not going to work on fixing any bugs in MVCC itself because Thomas is working on a replacement engine which does MVCC more naturally than our current engine. On 2013-09-30 12:17, Rui Vilão wrote: My application is stalling when using MVCC. I'm using the 1.3.173 version embedded in another application. -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
Re: [h2] Parameter Handling Bug
Hi, Ok sorry. I thought possibly it would be relatively easy to debug if you could see it happening. I can certainly create the test as a standalone stored procedure, and then I suppose I should have a go at removing bits to try and reduce it. In terms of h2 code is there a reason that the parameter references need to be copied in the manner that they are? In my simplistic understanding for a given stored procedure there will always be a fixed number of parameters, so in an ideal world a single data structure could be used to store those parameters. (Any generated sub queries would have to reference the parameters by number but presumably we always control that), I'll email an updated test case when I have it ready, regards, Mike On Sat, Sep 28, 2013 at 5:57 PM, Thomas Mueller thomas.tom.muel...@gmail.com wrote: Hi, Unfortunately, it's quite hard to analyze the problem with this test case. The test case doesn't include source code, and the statement is very large (500 lines or so). Would it be possible to simplify the test case to just a few lines of SQL statement, and to a simple, standalone test case with source code? Regards, Thomas On Wed, Sep 25, 2013 at 7:35 PM, Mike Goodwin mkpgood...@gmail.comwrote: I replied off the list with a link to download a test case. - mike On Tue, Sep 24, 2013 at 6:29 PM, Thomas Mueller thomas.tom.muel...@gmail.com wrote: Hi, There were a few issues about parameter indexes in combination with views or subqueries in the past, it's possible that there are remaining issues. I can provide a standalone, albeit complicated test case for this issue. That would be great! I wouldn't want to change the code without having a proper test case. Regards, Thomas Hi, I have found what I believe to be an issue with parameter handling in a complex query. It seems it is possible for the incorrect parameter to be returned as a value when evaluating the query (in my case a timestamp parameter was evaluating to a long - using the value of a separate parameter of from the query). The query itself is generated and quite complex with a fair amount of context so it is not trivial to make a stand alone test case for this. Below is the error. LIMIT 1 [22007-173] at org.h2.message.DbException.getJdbcSQLException(DbException.java:331) at org.h2.message.DbException.get(DbException.java:160) at org.h2.value.ValueTimestamp.parse(ValueTimestamp.java:87) at org.h2.value.Value.convertTo(Value.java:834) at org.h2.value.Value.getTimestamp(Value.java:395) at org.h2.expression.Function.getValueWithArgs(Function.java:1161) at org.h2.expression.Function.getValue(Function.java:466) at org.h2.expression.Operation.getValue(Operation.java:110) at org.h2.expression.Aggregate.updateAggregate(Aggregate.java:246) at org.h2.expression.Function.updateAggregate(Function.java:2117) at org.h2.expression.Function.updateAggregate(Function.java:2117) at org.h2.expression.Alias.updateAggregate(Alias.java:88) at org.h2.command.dml.Select.queryGroup(Select.java:344) at org.h2.command.dml.Select.queryWithoutCache(Select.java:620) at org.h2.command.dml.Query.query(Query.java:314) at org.h2.command.dml.Query.query(Query.java:284) at org.h2.index.ViewIndex.find(ViewIndex.java:253) at org.h2.index.BaseIndex.find(BaseIndex.java:126) at org.h2.index.IndexCursor.find(IndexCursor.java:155) at org.h2.table.TableFilter.next(TableFilter.java:328) at org.h2.table.TableFilter.next(TableFilter.java:398) at org.h2.table.TableFilter.next(TableFilter.java:398) at org.h2.table.TableFilter.next(TableFilter.java:398) at org.h2.command.dml.Select.queryGroup(Select.java:316) at org.h2.command.dml.Select.queryWithoutCache(Select.java:620) at org.h2.command.dml.Query.query(Query.java:314) at org.h2.command.dml.Query.query(Query.java:284) at org.h2.expression.Subquery.getValue(Subquery.java:37) at org.h2.expression.Function.getNullOrValue(Function.java:974) at org.h2.expression.Function.getSimpleValue(Function.java:815) at org.h2.expression.Function.getValueWithArgs(Function.java:992) at org.h2.expression.Function.getValue(Function.java:466) at org.h2.expression.Operation.getValue(Operation.java:110) at org.h2.expression.Function.getNullOrValue(Function.java:974) at org.h2.expression.Function.getValueWithArgs(Function.java:991) at org.h2.expression.Function.getValue(Function.java:466) at org.h2.engine.FunctionAlias$JavaMethod.getValue(FunctionAlias.java:361) at org.h2.expression.JavaFunction.getValue(JavaFunction.java:39) at org.h2.expression.ExpressionList.getValue(ExpressionList.java:33) at org.h2.expression.JavaAggregate.updateAggregate(JavaAggregate.java:194) at org.h2.expression.Function.updateAggregate(Function.java:2117) at
Re: [h2] Parameter Handling Bug
On 2013-09-30 14:16, Mike Goodwin wrote: In terms of h2 code is there a reason that the parameter references need to be copied in the manner that they are? In my simplistic understanding for a given stored procedure there will always be a fixed number of parameters, so in an ideal world a single data structure could be used to store those parameters. (Any generated sub queries would have to reference the parameters by number but presumably we always control that), Some functions take variable numbers of parameters, which complicates things. And then there are things which need to be re-evaluated because they're in a sub-query, etc, etc. SQL gets complicated fast :-( Your particular test-case appears to have a VIEW which uses an ALIAS FUNCTION (i.e. a Java stored procedure) to generate one of the the view's query parameters, and then the ALIAS seems to be querying another VIEW, which is __also__ getting the value of a query parameter from __another__ ALIAS. I look forward to seeing the reduced test-case, which I suspect will still be a doozy :-) -- 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 to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
