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
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?
- 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.
- Am I right in the assumption, that currently all request to the database are executed serial and not parallel?
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. ;-)
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
