This looks more like a code review :)
well, I think it's the only way to get used to ;-)
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)
ok, I just realized that we have/had a different understanding of a transaction and so on ;-)
In HSQLDB each operation on the table/index is encapsulated in a tx object.
In my understanding a transaction is a putting together of several table/index operations, that means everything between the 'set autocommit false' or last 'rollback/commit' command and a further 'commit/rollback' command. This is realized as the 'tTransaction' attribute in the Session class. So, I understand now. I hope, others do undstand it as well ;-)
Even more, the approach to encapsulate each table/index operation in a serveral transaction object is quite nice. It's useful to implement FOCC. Even though there are some modifications necessary to build up to proper Read-Sets (RS) and Write-Sets (WS) of each transaction - transaction in my understanding.
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.
tTransaction would get a new meaning in the context of MVC with FOCC, s.a. RS and WS
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.
Well, I don't want to change to much original code. So all new functionality will be implemented in their own packages.
I also probably would like to put all classes beloinging to the JDBC driver in a own package. The org.hsqldb package is a bit crammed full at the moment for my taste. ;-) (Again, no critism, just my opinion)
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
