Записки программиста, обо всем и ни о чем. Но, наверное, больше профессионального.

2015-03-22

Zope, ZODB и ACID

Памятка на тему конфликтов чтения-записи и прочей ACID-ности в БД Zope, ZODB.

ZODB provides execution time consistency by raising read conflict errors. A simple explanation of read conflict errors requires some extra details about how ZODB works. ZODB transactions execute in parallel. When one connection commits a transaction, it sends an invalidation message to all the other connections; the invalidation messages lists all the objects that were modified by the committed transaction. The next time another connection commits a transaction, it will apply the invalidation; i.e. it will ghostify all the objects in the invalidation message.
If a connection is asked to load an object from the database and it has received (but not applied) an invalidation message for the object, it raises a ReadConflictError. This error is necessary to avoid an inconsistent read. When ZODB loads an object from storage, it always reads the most recent revision. Since the connection has an invalidation message for the object, the object was modified after the transaction began. If it reads the current revision of that object, it could be inconsistent with other objects read before the transaction began.



The way ZODB and threading works is that each thread that uses the database gets its own connection to the database. Each connection gets its own copy of your object. All of the threads can read and change any of the objects. ZODB keeps all of these objects synchronized between the threads. The upshot is that you don’t have to do any locking or thread synchronization yourself. Your code can act as though it is single threaded.
However, synchronization problems can occur when objects are changed by two different threads at the same time.
Imagine that thread 1 gets its own copy of object A, as does thread 2. If thread 1 changes its copy of A, then thread 2 will not see those changes until thread 1 commits them. In cases where lots of objects are changing, this can cause thread 1 and 2 to try and commit changes to object 1 at the same time.
When this happens, ZODB lets one transaction do the commit (it “wins”) and raises a ‘ConflictError’ in the other thread (which “looses”).



def writing_to_zdb():
    zdb = open_db()

    retry = 0
    while retry < max_retry:
        try:
            # this is where you write to, delete from, & change the DB
            # for example, this creates a new {} that is persistent
            zdb['root']['new_dict'] = PersistentDict()

            transaction.get().commit()
        except ConflictError:
            retry += 1
            time.sleep(sleep_delay)
            pass
        else:
            break
    else:
        # retried too many times
        close_db(zdb)
        return "Error - transaction could not complete"

    close_db(zdb)
    return "Data written successfully"

Еще?






original post http://vasnake.blogspot.com/2015/03/zope-zodb-acid.html

Комментариев нет:

Отправить комментарий

Архив блога

Ярлыки

linux (241) python (191) citation (186) web-develop (170) gov.ru (159) video (124) бытовуха (115) sysadm (100) GIS (97) Zope(Plone) (88) бурчалки (84) Book (83) programming (82) грабли (77) Fun (76) development (73) windsurfing (72) Microsoft (64) hiload (62) internet provider (57) opensource (57) security (57) опыт (55) movie (52) Wisdom (51) ML (47) driving (45) hardware (45) language (45) money (42) JS (41) curse (40) bigdata (39) DBMS (38) ArcGIS (34) history (31) PDA (30) howto (30) holyday (29) Google (27) Oracle (27) tourism (27) virtbox (27) health (26) vacation (24) AI (23) Autodesk (23) SQL (23) Java (22) humor (22) knowledge (22) translate (20) CSS (19) cheatsheet (19) hack (19) Apache (16) Manager (15) web-browser (15) Никонов (15) functional programming (14) happiness (14) music (14) todo (14) PHP (13) course (13) scala (13) weapon (13) HTTP. Apache (12) Klaipeda (12) SSH (12) frameworks (12) hero (12) im (12) settings (12) HTML (11) SciTE (11) USA (11) crypto (11) game (11) map (11) HTTPD (9) ODF (9) купи/продай (9) Photo (8) benchmark (8) documentation (8) 3D (7) CS (7) DNS (7) NoSQL (7) cloud (7) django (7) gun (7) matroska (7) telephony (7) Microsoft Office (6) VCS (6) bluetooth (6) pidgin (6) proxy (6) Donald Knuth (5) ETL (5) NVIDIA (5) Palanga (5) REST (5) bash (5) flash (5) keyboard (5) price (5) samba (5) CGI (4) LISP (4) RoR (4) cache (4) car (4) display (4) holywar (4) nginx (4) pistol (4) spark (4) xml (4) Лебедев (4) IDE (3) IE8 (3) J2EE (3) NTFS (3) RDP (3) holiday (3) mount (3) Гоблин (3) кухня (3) урюк (3) AMQP (2) ERP (2) IE7 (2) NAS (2) Naudoc (2) PDF (2) address (2) air (2) british (2) coffee (2) fitness (2) font (2) ftp (2) fuckup (2) messaging (2) notify (2) sharepoint (2) ssl/tls (2) stardict (2) tests (2) tunnel (2) udev (2) APT (1) CRUD (1) Canyonlands (1) Cyprus (1) DVDShrink (1) Jabber (1) K9Copy (1) Matlab (1) Portugal (1) VBA (1) WD My Book (1) autoit (1) bike (1) cannabis (1) chat (1) concurrent (1) dbf (1) ext4 (1) idioten (1) join (1) krusader (1) license (1) life (1) migration (1) mindmap (1) navitel (1) pneumatic weapon (1) quiz (1) regexp (1) robot (1) science (1) serialization (1) spatial (1) tie (1) vim (1) Науру (1) крысы (1) налоги (1) пианино (1)