New to H2
sul...@gmail.com
I'm not sure if everyone knows, but I think that for the benefit of
this project and its users, all bug reports and enhancement requests
should go here: http://code.google.com/p/h2database/
Having a clear image of the bugs is capital for a project. (Thomas,
can you allow reporters to set the kind and priority of their report?)
I believe that this area should be kept for discussions only. Thomas
Mueller has done a good job of maintaining the bug list in the Roadmap
page so far, but I don't think this should be a permanent solution to
the problem that Google does not integrate Google Code and Google
Groups.
And yes, I have something interesting to say, too :)
H2 is a relatively new database engine, with more or less severe
issues. But I for one haven't spotted anything shameful in the Roadmap
(read bug list). It makes me hope that the 1.2 version will actually
be recommendable in less-demanding production environments against ALL
other open source alternatives.
H2 has also got the speed advantage over other databases, there's no
question about it.
But there's a fundamental thing that still lacks here: concurrent
transactions support. There's a big step made towards it, namely
supporting the SERIALIZABLE isolation level. Unfortunately, using
table-level locking makes it difficult (if not impossible) to use H2
in "long" concurrent transactions, let alone it is a policy that
doesn't scale at all. I'm aware there a MVCC mode of operation, not
mature yet.
What I propose is to turn into a top priority (zero, not 1 ;) )
converting the locking mechanism to a row-level one. That's the only
key point still missing at H2. Features can be added later...
Thanks for reading.
Thomas Mueller
> all bug reports and enhancement requests
> should go here: http://code.google.com/p/h2database
I'm still undecided about this. It does sound like additional
'administrative work', on the other hand users can more easily get the
list of known open issues, and the process is well defined.
> Having a clear image of the bugs is capital for a project. (Thomas,
> can you allow reporters to set the kind and priority of their report?)
The Google Code issue tracking doesn't have a lot of features. I have
changed the template for new issues now, could you please review it
and tell me what you think about it?
> I believe that this area should be kept for discussions only.
It doesn't matter to me. However if people think the list should be
split please tell me.
> concurrent transactions support.
This is an area that need more testing. The MVCC (multi version
concurrency) feature is a bit different than PostgreSQL MVCC and
Oracle MVCC, this needs to be documented and better tested as well
(and it may need to be changed). Row level locking needs to be
implemented, but in my view MVCC testing is more important just now.
> "long" concurrent transactions
Yes. However I think that very long or large transactions should be
split into smaller transactions, and 'compensations' should be used.
Not only because of H2, but because it makes more sense. My plan was
to write additional documentation about that, and maybe a tool to
simplify development. See also:
http://en.wikipedia.org/wiki/Long-running_transaction
> What I propose is to turn into a top priority (zero, not 1 ;) )
> converting the locking mechanism to a row-level one. That's the only
> key point still missing at H2. Features can be added later...
Thanks! It's very important to know what people view as important.
Regards,
Thomas