Dear comp.databases.theory Group,

over the last one or two years you helped me a couple of times when i
asked silly questions, mainly about transactions, isolation levels
etc.

Now i'm really happy to tell you that i finally released the first
beta version of hamsterdb Transactional Storage. if you're curious
about implementation details, feel free to ask, look at the source or
read the whitepaper (link is below).

In a nutshell:
* ACID compliant transactions in a lock-free architecture;
Transactions do not hold locks during their life-time. Conflicts are
resolved in memory, without accessing the disk
* Fast; performance-relevant functions are moved to the background
* Logical, idempotent logging and Recovery
* Multithreaded; every handle can be used from arbitrary threads
* portable ANSI-C code (Linux/Unix/Win32)
* Easy to use

Source:
http://hamsterdb.com/public/dl/hamsterdb2-0.0.1.tar.gz

The linux/unix version is stable - but win32 still has some issues
(although it works most of the time). This release is not intended for
production use.

The next releases will improve performance, improve win32 and add more
features (Cursors, duplicate keys, more transaction isolation
levels...)

Whitepaper:
http://hamsterdb.com/public/dl/hamst...l_overview.pdf

Best regards
Christoph

Christoph Rupp wrote:

You are welcome.

Not supporting cursors would actually be a good *feature* IMO.

"Duplicate keys" sounds like it could be a contradiction in terms,
unless you are talking about duplicate (non-unique) *physical* keys.

--
Roy

On Jul 20, 2:26*am, Christoph Rupp <cruppst... (AT) gmail (DOT) com> wrote:
quoting now from the white paper:


yes you prevent dirty reads, but concurrent transactions must all
finish
(unless one rolls itself back on a constraint violation).
you have to support concurrency before "isolation level" makes any
sense.

you still don't understand the basic concepts.

philip

On Jul 22, 1:21*pm, com... (AT) hotmail (DOT) com wrote:
feel free to explain them to me.

Christoph

On Jul 31, 7:10*am, Christoph Rupp <cruppst... (AT) gmail (DOT) com> wrote:
In my previous message I meant to bear bad tidings,
but I didn't mean to have an attitude.

To expand on my previous message:
1. You have locks.
"Locking" just means others' access is constrained.
Latches and mutexes are locks.
2. A system only has concurrency if each user's sequence
of transactions proceeds despite other transactions.
Isolation level is one way to define the kind of atomic
changes that a transaction is a sequence of from
the user's point of view.
(You don't seem to understand that isolation levels other
than serializable violate ACID, unless you interpret the
atomic changes as nested transactions.)
The system must produce some interleaving of these
atomic changes.
Rollback and commitment are implementation
concepts dealing with (user-invisible) attempted executions
of individual transactions or atomic changes.
Each user must see their transactions advance
(observing also non-deterministic atomic changes from
other transactions between their own atomic changes).

I said these are basic concepts. If I haven't motivated
you to re-examine some basic expositions, so be it.

philip

Philip,

On Aug 2, 9:41*am, com... (AT) hotmail (DOT) com wrote:

My "lock-free" described the implementation and the fact that i do not
lock pages. I'll make sure that next time i'm understood better

i think i understand your points. I also understand that the 'i' in
ACID is violated if the isolation level is not SERIALIZABLE. on the
other hand even ANSI suggests different/weaker isolation levels. I
guess i follow a more pragmatic approach - also in case of
concurrency, .

Actually i'm grateful for your comments. my database is a hobby
project and i'm happy to learn and improve my knowledge. I'd
appreciate book recommendations.

Christoph

In the case of databases that's SQL companies.
Standard doesn't mean good.

Perhaps as if theoretical or abstract meant impractical,
instead of "sound", "clear" and "fundamental".

A classic & good beginning is Date's Intro to DB Systems.
The classic reference is Gray and Reuter
Transaction Processing: Concepts and Techniques.
On the other hand Gray never understood the relational model.
Berstein has a 2009 edition of Principles of Transaction Processing.

philip

On Aug 3, 5:49*am, com... (AT) hotmail (DOT) com wrote:
No, not at all. Read it as "Accept something imperfect if it's good
enough to solve most problems effectively (and then improve the
solution step by step)". I think this comes from my development style
which is based on iterations.

Thanks for the book recommendations and your other comments.

Christoph

compdb (AT) hotmail (DOT) com wrote:
That's interesting. Can you point me to some evidence of that?
Just out of curiosity, mind, I'm not saying I disbelieve you.
But it seems rather surprising...

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design

On Sep 25, 8:46*pm, noyb <no.s... (AT) please (DOT) net> wrote:
I might have come to this conclusion because of "A Call to Arms".

philip