Also a big thanks from me for sharing your experiences in such a clear
headed fashion.
There are people on this list who are interested to hear other people's
experiences about h2 codebase.
And to hear comparisons with other databases was most interesting!
- rami
On 9.4.2010 10:15, James Gregurich wrote:
The key feature that attracted my attention was MVCC. Based on what I have
read, that technique is what all the big boys are using to maximize their
performance. I figured that approach would likely work well for my needs.
I also spent time studying the source code for Firebird& Postgresql to see if
I could adapt either of them to work as an embedded db. Neither project was coded
very well. Firebird's code seemed fairly chaotic....though better than SQLite.
PostgresSQL is fairly well-written, but has an insufficient level of abstraction.
It's code is too married to the original way it was intended to run..namely a
collection of processes that communicate via IPC. It would be a major effort to
yank out all the IPC and replace it with normal mutexes and memory management.
Firebird would be easier to adapt, but it was still not trivial because their code
isn't well written. It is hard to trace through Firebird's code and figure out how
it works. Firebird needs to be coded from scratch using modern C++ techniques.
Finally, I'm doing commercial software with lots of proprietary IP....so
anything GPL is poison....can't use it.
H2's code is fairly well written and structured. Its easy to follow, understand
and trace through. The license doesn't require me to make our core intellectual
property public. So, It is the best choice IMO.
I'd say the authors of H2 should have been more disciplined when coding, but overall,
they did a good job. There tends to be a fair amount of redundant storing of references
to objects. For instance, if a subclass needs a reference to an object and its parent
already has a reference to that object, instead of reusing the parent's reference, the
subclass stores a second reference to it. Also, there needs to be religious use of
prefixes to distinguish data members, local variables and static variables from one
another. naming variables like "newConnection" with no indication of scope
makes code harder to read and understand. Also, I prefer better encapsulation of data
members. I instruct my guys that only constructors, destructors and accessor functions
may directly reference data members...all other member functions must go through
accessors....its a little extra work up front to write accessors, but it generally pays
for itself when you need to evolve the code later on.
BTW: I did discover what I think is a race condition in SET EXCLUSIVE if
multithreaded mode is on. It looked to me like you could end up with two
sessions thinking they had exclusive access. However, that was in an older
version of your code. You may have fixed that by now. I don't know yet. I just
refreshed my copy of your repository today after many months.
On Apr 8, 2010, at 11:47 PM, Sylvain Pointeau wrote:
Seems interesting, could you point on the issues in sqlite3 and compare them
with H2 and how H2 solved them?
Best regards,
Sylvain
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
