There is no major difference between HSQLDB's understanding of a transaction and the general use of this. As you say a transaction is basically what happens between two ROLLBACK/COMMIT commands. Obviously different implementation will need different internal data structures and these should be named appropriately.
Re packaging, it might be a good idea to change things at some point in the future, but any publicly visible change would have an effect on the programs that use HSQLDB. For example, putting the JDBC classes in a different package would mean changing the connection code. You are free to put your additions in a new Java package. Fred ----- Original Message ----- From: "Daniel Schaller" <[EMAIL PROTECTED]> To: "fredt" <[EMAIL PROTECTED]>; "HSQL Developer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 21 January 2004 08:29 Subject: Re: [Hsqldb-developers] Nested transactions not grouped in a parent transaction On Tue, 20 Jan 2004 22:59:34 -0000, fredt <[EMAIL PROTECTED]> wrote with possible deletions: > 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 ------------------------------------------------------- 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
