[pypy-dev] Redis «clone» using pypy stm-thread-2 (Was: Redis clone)

Amirouche Boubekki amirouche.boubekki at gmail.com
Sat Apr 13 08:37:48 CEST 2013


2013/4/12 Armin Rigo <arigo at tunes.org>

> Re,
>
> ...and of course there is the fundamental question: what is the link
> between STM transactions and database transactions?  How do we write
> programs that use large-scale "with atomic" statements and that want
> to access an ACID database subsystem?


In the case of graphitidb, it's a MVCC which aims to avoid locks hence
«with atomic». A DBT is considered commited if it can be read by other
transaction (aka. can read the modifications done by the transaction) and
this is possible when its transaction id is put in the in memory
transaction store. So you need a «with atomic» to update the transaction
store and you need «with atomic»s to update the MVCC graph hence the DBT is
not directly related to «with atomic» transactions and of course DBT can
fail even whatever the actual behavior of «with atomic»s.

Regarding the usecase you present a «with atomic» that does modification of
an ACID database, the «atomic» rollback of «with atomic» must be overriden
to rollback the database and must commit the ACID database when the «with
atomic» suceeeds. Also what happens if the DBT fails ? the ST should also
be rolledback and be tried again. I think this is a usecase for two phase
commit aka. 2PC [1] used in distributed DB settings.


> Do you or anyone know of a paper that explores this?
>

No. Except I think it's a usecase for 2PC, I'm not sure how this related to
python transaction module.

HTH,

Amirouche

[1] https://en.wikipedia.org/wiki/Two-phase_commit_protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130413/9e2c984b/attachment.html>


More information about the pypy-dev mailing list