This looks more like a code review :) The following two commands are executed as nested transactions:
INSERT INTO ... SELECT... FROM .. UPDATE ... The reason INSERT and DELETE are not, is because adequate checks for referential integrity and NOT NULL constraints could be performed without inserting or deleting the rows. With the above commands, however, those checks could not be performed without actually performing the action. Since that time, changes have been made to the implementation of the UPDATE command and recently CHECK constraints have been introduced. I think, UPDATE now performs the checks before performing the action and , with some lines of code, the required checks for INSERT INTO ... SELECT ... FROM can be made before insertion. The difference between nested transaction and others should be obvious. If autocommit is false, you want the last UPDATE to roll back if it is not successful, but you don't want the previously executed commands to roll back. I don't see what good it would do to group the UPDATE nested transaction commands. These commands are rolled back immediately if the action is not successful. Otherwise, they become just ordinary members of the transaction list. You can think of nested transaction as a SAVEPOINT to which we immediately roll back if the command is not successful. It might be an idea to use the internal SAVEPOINT semantics for any nested transactions (if we find out we still need them) In any case, with a multi-version concurrency scheme, transaction control would be done differently and we may not have memory resident lists such as tTransaction. Re visibility of Database, etc. All the HSQLDB core is in one package to make life simple. Only those classes that are accessed from outside are Public. All the rest are package-private. If your changes need some classes to become public, then it should be fine to change the visibility. Fred ----- Original Message ----- From: "Daniel Schaller" <[EMAIL PROTECTED]> To: "HSQL Developer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 20 January 2004 21:41 Subject: [Hsqldb-developers] Nested transactions not grouped in a parent transaction Hi, just found out the following: A delete or a insert command, which effect more then one tuple/row, is transformed in several inserts or deletes on the table/index. Each of theses inserts/deletes is put in a own transaction object to perform a rollback if necessary. The flag 'isNested' is false in these transaction (tx) objects. Theses tx are added to the list 'tTransaction' of the current session. If you perfom an update, which usually results in several deletes and inserts on the table/index, there will be tx objects created too. However, in this case, the flag 'isNested' is set to true. Finally, the tx objects are added to the list 'tTransaction' in the current session to. My questions: - What's the difference between these tx objects. - Why are not the tx objects with 'isNested == true' grouped in a parent transaction which represents the Update command. I think, it would be a good idea, wouldn't it? Regards, Daniel P.S. Some classes in org.hsqldb have no visbility modifier like private or public, e.g. Database, Transaction. Is there a reason for it or just forgotten? Anyway, I will and have to change it for my modifications. ------------------------------------------------------- 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
