comments inline Fred
----- Original Message ----- From: "Daniel Schaller" <[EMAIL PROTECTED]> To: "fredt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 18 January 2004 18:26 Subject: Re: [Hsqldb-developers] Better Transaction Handling and Cache Enhancement On Sun, 18 Jan 2004 17:34:11 -0000, fredt <[EMAIL PROTECTED]> wrote with possible deletions: > Re HSQLDB/R, it is not complicated as it uses a well developed framework > for > replication. The HSQLDB side though must be improved with better > transaction > isolation so that only committed transactions are replicated. Does it also work with the 1.7.2 RC1 candidate. I ask because it is mentioned that it works with 1.7.2 Alpha_B version ------------------ HSQLDB/R was recently converted by someone to work with RC1 but I haven't got the code. I have asked him to send it. Even the old version can easily be converted. ------------------ > No direct work has been done on multi-version concurrency but some side > issues have been fixed to allow this. In short, with the current indexing > and persistence scheme, it should be possible to retrofit the AVL > indexes to > store and return different rows from different sessions, depending on the > transaction isolation level set for the current session. My proposed > solution is to add both inserted rows and deleted rows for each session, > with the deleted rows marked as such and both types having a session id. > Index search and traversal will take the id's and flags into account to > return only the rows that are visible in the session context. Ok, some other questions, I hope it's ok: - Is the index (implemented as as AVL tree) the common way to access the data from a table? Is the index always used? Or: how must the index be seen in relation with the table? ----------------- Yes. All access to data is via indexes. For tables without explicit primary keys, there is a hidden one backed by an index. ----------------- - Multi-version concurrency control (MVC) demands a strategy to keep Write-TX consistent. We want to use FOCC (forward oriented concurrency control). For this, we need global (logical) timestamps, which we want to create by the Lamport procedure. I hope I can find out how the classes Table, Index and so on work. If I know that, I can say more about what modifications would be necessary and so on. ----------------- That's fine in prinicple. We will discuss the details once you have studied the existing code a bit more. To find out, look at the methods for insert and delete in Table. It goes through the list of indexes and inserts/deletes the row into/from each index. That's all. No count of the rows or other information is kept. A table is empty when its index root node is null. ----------------- - Am I right in the assumption, that currently all request to the database are executed serial and not parallel? ----------------- Yes. The future plan is to change this with table level locking so that ideally the engine blocks only for one row insert/delete. ----------------- And just for my interest: - Who or why did the decision come into being using a AVL tree as index data structure and not the well-known B-Tree (or one of its sub-classes)? And was the descision made to name a table which is written to the disk as "cached" table? I find this terminology a bit confusing due to in other databases a normal table is written to disk. When I heard "cached table" the first time in the HSQLDB context, I thought this is a in-memory table. However, here it is the very opposite: a normal table is a in-memory table, a "cached table" is written to disk. Maybe you know how this came into being. It's not critism at all, just interest. ;-) ------------------- HSQLDB is based on Hypresonic and these decisions were made by Thomas, the original author. AVL trees are OK, especially for searching, but they take up more memory than B-Tree and its derivatives. Also, because of their homogenous structure, AVL indexe nodes are easier to read/write to disk with the data. In HSQLDB, the nodes from different indexes for each row are written together with the row data. A CACHED table is so called because a number of rows from the disk are cached in memory. A MEMORY table is fully memory-resident and is written to disk as SQL statements. ---------------------- Regards, Daniel ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
