Is Software Transactional Memory the same as database transactions?

Question

I have read alot about Software Transactional Memory, especially in relation to Haskell but I am trying to figure how it is different from database transactions? Are there some advantages I do not understand with STM?

Seawards

Answer 1

The idea of a "transaction" in software transactional memory is explicitly borrowed from databases. The difference is where the transactions are implemented and how they are used.

STM is a language-level concept: a sequence of operations does not take effect until a transaction is committed. Typically this means that the values of some global/shared variables only change when a transaction succeeds. The property is enforced by the language runtime. There is no inherent notion of persistence: the variables involved in a transaction may be purely dynamic in nature (e.g., the size of a work queue).

Database transactions are an application-level concept: a sequence of data operations do not take effect until the transaction is committed. Since this is a database, persistence is fundamental: the meaning of "taking effect" inside of a database is that the data is saved in some persistent store.

You could potentially use a database and database transactions to implement a STM-style algorithm, but you'd lose the ease and convenience (and probably in most cases the performance) of a language-level implementation.

Trifle

What do you mean by an "operation"? Do you mean the running code? – Seawards

Yes, exactly. In STM, the effects of the code within the transaction (e.g., assignments to variables, I/O) aren't visible until the transaction is "committed". – Trifle

Answer 2

An STM transaction has a lot in common with a database transaction. In particular, of the ACID properties important to database designers, STM provides Atomicity and Isolation. Consistency, however, is up to the programmer—you can write STM transactions that violate the invariants of internal data structures, for example. Finally, STM transactions typically are not Durable; results are stored in volatile RAM, and if the machine crashes after a successful transaction, the results can be lost. That, in my mind, is probably the most salient difference between an STM transaction and a database transaction.

Ailin

If you can encode your invariants in the type system, then you can't write inconsistently. – Simplicidentate

Are in-memory sql dbs like voltdb then similar to replicated (across a few machines) STM to provide durability? – Monazite

Answer 3

STM is mostly used for concurrency, while database transactions are about data consistency.

Wendellwendi

In databases there are explicit invariants that can be specified and maintained, mostly about preserving mappings between key fields across tables. If I have tables "Customer" and "Address" then I can specify that every Address must have a matching Customer, and the database will maintain this. Haskell STM doesn't do this. – Samhita

@Paul in my opinion, this kind of consistency is not exclusive of databases. You can always enforce an invariant inside a STM transaction. – Legg