Title: Re: [python] Lock
Stejně mi není jasné proč to nefungovalo.
Server je wsgi daemon a je spuštěn s jením procesem a 25 threadu.
Pak by měl threading.Lock fungovat.
Mirek
9. února 2015, 13:39:48, napsal jste:
Web server miva typicky vice procesu a tak
Jak jsou jednotlivé zprávy od sebe odděleny? Vidím tam v klientovi
def communicate(self, data):
self._socket.send('%s %s' % (self.name, data))
self._socket.recv(self.buffer_size)
A server to čte takto:
while True:
data =
Tohle skutecne neni dobre reseni - napriklad vubec neresi
synchronizaci pristupu ke globalnimu registru zamku a tak to nema
zadnou garanci, ze to skutecne bude fungovat. Namatkou radek 140 kde
se klidne muze stat ze dve vlakna provedou ten samy test a kazde si
vytvori vlastni zamek se stejnym
Jeste existuje tzv. DLM (Distributed Lock Manager). Zjednodusene receno, je to
mutex, ktery je pristupny po siti.
Jeden takovy jednoduchy distributed lock manager jsem napsal v pythonu a
umistil na activestate zde:
http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
Transakce jsem použít nechtěl, protože databáze nemusí být innodb dokonce
ani mysql.
Takové databáze jsou pro aplikace pracující s penězi nejlepší. Už chybí jen
náhodné mazání uložených dat.
PM
___
Python mailing list
python@py.cz
Title: Re: [python] Lock
Já tedy nevím, co je třeba na myisam špatného pro práci s penězi.
1. Potřebuju aplikaci, která je více nezávislá na druhu databáze.
2. Transakce pro write to neřeší, jedině read a tu vzhledem k možné době trvání zámku nechci použít
Nicméně už sem to vyřešil
a protoze ve svete bezstavovych webovych workeru bychom se na lokalni
filesystem spolehat opravdu nemeli, tak kdyz uz kladivo, tak opravdove:
cili zamek v nejakej sdilenem ulozisti, treba v te databazi, coz jsme
pomerne blizko i tem transakcim.
2015-02-09 15:01 GMT+01:00 Vladimir Macek
V zasade si muzes vybrat jeden z nekolika pozadavku, jinak se proste
nevytocis (v tomto poradi, idealne):
- Bude ta SQL umet syntax, co uvadi Honza
- Bude podporovat transakce
- Pouzijes nejaky zamykani pres spolecne uloziste - viz Jakub (bud neco
znova v ty SQL, nebo trebas nejakej redis
Transakce jsem použít nechtěl, protože databáze nemusí být innodb
dokonce ani mysql.
Kazda poradna databaze umi transakce a zamykani, protoze to je zpusob
jak se tyhle problemy spravne resi. A resi je podstatne lepe nez to kdyz
dokazes napsat ty. Rozhodne je resi lepe nez bych to napsal ja,
a to
Jestli potřebuješ aplikaci, která je nezávislá na druhu databáze, použij
SQLAlchemy, která ti poskytne abstrakci nad různými databázovými backendy.
Jinak na myisam i innodb je špatné to, že nejsou ACID a dříve nebo později
tě někde pořádně vypečou. Jak už psal Honza Král, 99% problémů s databází
2015-02-09 18:50 GMT+01:00 Petr Messner petr.mess...@gmail.com:
V čem není InnoDB ACID, při nastavení patřičného isolation levelu?
InnoDB má solidní bug v transakcích, kvůli kterému nesplňuje ACID. Neumí
udělat rollback ALTERu, takže ALTER se autocommituje vždy, i když zbytek
transakce se
V čem není InnoDB ACID, při nastavení patřičného isolation levelu?
PM
Dne pondělí 9. února 2015 Jan Bednařík jan.bedna...@gmail.com napsal(a):
Jestli potřebuješ aplikaci, která je nezávislá na druhu databáze, použij
SQLAlchemy, která ti poskytne abstrakci nad různými databázovými backendy.
MariaDB je to stejně špatně?
Dne 9.2.2015 v 21:13 Jan Bednařík napsal(a):
2015-02-09 18:50 GMT+01:00 Petr Messner petr.mess...@gmail.com
mailto:petr.mess...@gmail.com:
V čem není InnoDB ACID, při nastavení patřičného isolation levelu?
InnoDB má solidní bug v transakcích, kvůli
Existuje na to i opravdu kladivo: souborovy zamek.
Na lokalnim souborovem systemu mas zaruceno, ze v kriticke sekci se bude
pohybovat jen jeden thread. Pouzivam i u webovych aplikaci v sekcich, kde
potrebuju uplnou jistotu.
Implementaci prevzatou z webu najdes napr. v me sade nastroju:
A samozrejme, jako vzdy, je lepsi varianta bezzamkova:
UPDATE Zaplaceno = 1 FROM platby WHERE id=%s AND Zaplaceno = 0
Honza Král
E-Mail: honza.k...@gmail.com
Phone: +420 606 678585
2015-02-09 11:42 GMT+01:00 mtip m...@atlas.cz:
Ahoj,
narazil jsem na problém se zámkem.
Mám aplikaci na web
Title: Re: [python] Lock
Díky za postrčení, nedošlo mi, že to může být jiný proces a ne thread.
Transakce jsem použít nechtěl, protože databáze nemusí být innodb dokonce ani mysql.
Mirek
9. února 2015, 13:39:48, napsal jste:
Web server miva typicky vice
Jestli nemusi byt MySQL tak mas napul vyhrano - MySQL je v 99% ten problem.
/rant
Honza Král
E-Mail: honza.k...@gmail.com
Phone: +420 606 678585
2015-02-09 15:13 GMT+01:00 mtip m...@atlas.cz:
Díky za postrčení, nedošlo mi, že to může být jiný proces a ne thread.
Transakce jsem použít
Ahoj,
narazil jsem na problém se zámkem.
Mám aplikaci na web serveru, která ukládá příznak booolean Zaplaceno
do MySQL databáze.
Občas se ale stane, že potvrzení platby přijde najednou ve stejný čas
ze dvou zdrojů. Chtěl jsem to vyřešit zámkem, což ale nepomůže.
Princip kódu:
from threading
Jo, MariaDB je na tom stejně, viz.:
https://mariadb.com/kb/en/mariadb/sql-statements-that-cause-an-implicit-commit/
2015-02-09 22:03 GMT+01:00 zu1234 zu1...@seznam.cz:
MariaDB je to stejně špatně?
Dne 9.2.2015 v 21:13 Jan Bednařík napsal(a):
2015-02-09 18:50 GMT+01:00 Petr Messner
Ahoj,
no, jestli ten kód vypadá opravdu přesně takto, tak dělá tohle:
* vytvoří úplně nový zámek a acquirene ho.
* udělá to sql
* releasene zámek.
No a druhý případný thread dělá to stejné:
* vytvoří úplně nový zámek a acquirene ho.
* udělá to sql
* releasene zámek.
Takže nic ničemu v ničem
Web server miva typicky vice procesu a tak lokalni zamky nebudou fungovat.
Presne na tyhle veci se ale hodi db transakce, rozhidne lepsi nastroj -
podivej se na 'select ... for update' a 'isolation level'.
On Feb 9, 2015 11:43 AM, mtip m...@atlas.cz wrote:
Ahoj,
narazil jsem na problém se
21 matches
Mail list logo
