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.
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. Fred ----- Original Message ----- From: "Daniel Schaller" <[EMAIL PROTECTED]> To: "fredt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 18 January 2004 17:04 Subject: Re: [Hsqldb-developers] Better Transaction Handling and Cache Enhancement Hallo Fred, Thanks for your quick response. On Sun, 18 Jan 2004 16:42:14 -0000, fredt <[EMAIL PROTECTED]> wrote with possible deletions: > This simple scheme means changes by other sessions are visible > (READ_UNCOMMITTED) and conflicts between actions by two sessions are not > resolved. I have read this in the documentation. That was one reason why I thought, our developments might be interesting for the HSQLDB community. > Yes, support for this has been developed as proof of concept (HSQLDB/R by > Bela Ban - downloadable from our files section) using JGroups. We would > like > to make this a standard extension when we have improved the core for > wider > transaction isolation support. We will look, if we could use it for our purpose. If not or if it is to complicated to get used to, we will try to implement a simple solution which should have, however, well defined interfaces. > We would like to move to multi-version concurrency control in the core > (it > is possible to do this without radical changes). Are there already ongoing works for it or is it "only" point on the to-do list? > I don't know what > "cache-constrained based caching enhancements" is, but any enhancement > sounds like a good idea :) Your work could fit neatly with our future > plans > so I would welcome your involvement. ok, we will try to have a short description of it in English within the next days. However, just for your information: it is based on ongoing research works of IBM. 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
