This looks more like a code review :)
The following two commands are executed as nested transactions:
INSERT INTO ... SELECT... FROM ..
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
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
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
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
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.
----- Original Message -----
From: "Daniel Schaller" <daniel@...>
To: "HSQL Developer" <hsqldb-developers@...>
Sent: 20 January 2004 21:41
Subject: [Hsqldb-developers] Nested transactions not grouped in a parent
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.
- 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?
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.
hsqldb-developers mailing list