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.
