6

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?

Don Stewart
  • 134,643
  • 35
  • 355
  • 461
yazz.com
  • 52,748
  • 62
  • 227
  • 363

3 Answers3

5

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.

Chris Conway
  • 52,725
  • 40
  • 121
  • 150
  • What do you mean by an "operation"? Do you mean the running code? – yazz.com Mar 24 '10 at 08:02
  • 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". – Chris Conway Mar 24 '10 at 13:43
4

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.

Norman Ramsey
  • 188,173
  • 57
  • 343
  • 523
1

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

user38123
  • 669
  • 3
  • 5
  • 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. – Paul Johnson Mar 23 '10 at 08:05
  • 1
    @Paul in my opinion, this kind of consistency is not exclusive of databases. You can always enforce an invariant inside a STM transaction. – Vicente Botet Escriba May 18 '10 at 22:06