Re: [Hsqldb-developers] Transactions in Hsql

Sun, 27 Mar 2005 02:08:14 -0800

Yes, the book mentions an important principle which some inexperienced programmers do not upderstand.
 
A DBMS cannot ensure consistency, as the meaning of this is always defined as a business rule and is application-dependent.
 
The LockFile class prevents two separate java processess to open the database at the same time. It has no role in managing transaction capabilities. Once a process has opened the database, the lock file prevents any other process to open it.
 
Regarding Isolation, older versions allowed two uncommitted transactions both to modify the same rows. The current version in CVS disallows this. It maintains a write lock.
 
Regarding persistence, durability is achieved by writing all insert and update operations to the .log file as they occur. The Table class activates the write and it is performed by the ScriptWriterText class.
 
BTW. If you have not actually done much coding work for your project, I would recommend to focus your attention on the CVS version of 1.8.0 (or at least RC9) which is up to date. This will make your work more useful. The program structure has not changed since 1.7.3, but improtant aspects such as TX support are changing.
 
 
Fred
 
----- Original Message -----
From: Irum Godil
Sent: 27 March 2005 05:20
Subject: Re: [Hsqldb-developers] Transactions in Hsql

Hi Fred,
 
I was reading a book on Transaction Management namely: "Databases and Transaction Processing" by Lewis, Bernstein and Kifer; and I have gotten a little confused as to the Transaction Support in HSQL. Following are my concerns and I will really appreciate if you can answer them:
 
1) On Consistency: In chapter 20 the book mentions that: "Keep in mind that producing consistent transactions is the sole responsibility of teh application programmer. The remainder of the transaction processing system takes consistecny as a given and provides atomicity, isolation and durability..."
 
Also, at another point the book mentions that: "It is the transaction designer's job to design consistent transactions. It is assumed that the Transaction Processing monitor provides the abstraction of atomicity, isolation, and durability".
 
From this my concern is that is there no support in the HSQL code base to support "Consistency" in transactions? Is it only the job of the person writing the transactions to ensure that transactions are consistent? If there is support in HSQL code base purely for the "Consistency" feature in ACID, then where and what is it? This is extremely important for my project since I want to refactor those places out.
 
2) Isolation: You have mentioned below in your email that HSQL does not support Isolation levels. But then what is the purpose of the LockFile class that is present?
 
Also, since HSQL supports READ-UNCOMMITED Isolation, there should be some way of obtatining and releasing locks for the write operations right, so where and how are these implemented?
 
Also, is the entire table locked for writing operations; or what is exactly locked?
 
3) Persistence:
You have mentioned below that Durability is achieved by persisting data to one or two files. Which files are these and again which classes in HSQL support this. I understand it to be the Logger and the Log classes; but those maintain the log right. Is the database stored separately in some other file?
 
I will really appreciate your responses to the above and they will tremendously help me in my research.
 
Thanks.
Sincerely,
Irum Godil .
 
 

fredt <[EMAIL PROTECTED]> wrote:
Your understanding of the implementation is correct. There is no transaction isolation in the version you have studied, but this feature is being added. The methods for isolation levels are part of the JDBC standard.
 
Isolation may be necessary for certain applications, especially existing and legacy applications. But serious applications such as banking can be designed with highly normalised schemas without any transaction isolation.
 
Durability is achieved by persisting data to one or two files. HSQLDB use file sync so that changes to data are fully persisted at user-defined intervals. This translates to about 99.999% reliability for new data, given an average one crash a day. As actual systems are probably 10 - 100 times more reliable, then it translates to up to 99.99999% reliability. Note that even in the event of a crash, the record of data changes that occured prior to the last interval would remain intact.
 
Fred Toussi
----- Original Message -----
From: Irum Godil
Sent: 28 February 2005 16:26
Subject: [Hsqldb-developers] Transactions in Hsql

Hi,
 
I am a graduate student at the University of Toronto. I am working in Aspect Oriented Refactorings, and am interested in exploring the HSql codebase for Transactions refactoring.
 
I would like to understand how are transactions implemented in HSql. From my inspection of Hsql code base, I have come to the following conclusions. I was hoping if someone can confirm that these are correct, and also point out anything I may have left out.
 
1) Atomicity: Atomicity is obtained via commit and Rollback features. By default AutoCommit is turned on, but if we want to treat a collection of commands as a transaction, then we could set autoCommit(false) and have explicit commit after the statements
 
2) Consistency: This is obtained via Locking the Database file while it is being used, and supported via LockFile.java class and its uses
 
3) Isolation Level: I see that HSql supports Transaction_Read_Uncommited, however in the code I only saw calls to setting and getting the isolation level. What other classes/methods support Isolation in HSql?
 
4) Durabiltiy: I am assuming that the whole org.hsqldb.persist package is supporting this via persisting data. Am I right?
 
Are there any documentations available on Transactions in HSql? I will really appreciate your help on this.
 
Thanks a lot.
Sincerely,
Irum Godil.

Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!

Reply via email to