Hi,
I and a fellow student of me are currently working on our diploma thesis
at the Dresden University of Technology (Germany), Chair for Database
Technology.
Our thesises deal about multi-version concurrency control and
cache-constrained based caching enhancements in relational databases.
Hallo Fred,
Thanks for your quick response.
On Sun, 18 Jan 2004 16:42:14 -, fredt <[EMAIL PROTECTED]>
wrote with possible deletions:
This simple scheme means changes by other sessions are visible
(READ_UNCOMMITTED) and conflicts between actions by two sessions are not
resolved.
I have rea
On Sun, 18 Jan 2004 17:34:11 -, fredt <[EMAIL PROTECTED]>
wrote with possible deletions:
Re HSQLDB/R, it is not complicated as it uses a well developed framework
for
replication. The HSQLDB side though must be improved with better
transaction
isolation so that only committed transactions
On Sun, 18 Jan 2004 19:41:39 +0100, Harald Niesche <[EMAIL PROTECTED]> wrote
with possible deletions:
Daniel Schaller wrote:
Fredt wrote:
I don't know what
"cache-constrained based caching enhancements" is, but any enhancement
sounds like a good idea :) Your work coul
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
On Tue, 20 Jan 2004 22:59:34 -, 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 l
On Wed, 21 Jan 2004 09:34:15 -, fredt <[EMAIL PROTECTED]>
wrote with possible deletions:
Thanks Fred.
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 co
