Re: [python] db a thready

[gsl na seznam.cz]

Dekuji za odpoved, problem jsem uz sice vyresil, viz. predchozi 
prispevek, ale ciste teoreticky k vecem co mi nejsou jasne.

< Pokud to chapu zpravne, bude ta DB lokalni tomu ip serveru. Mozna 
< dokonce i v tom samem address space. Potom mi prijde nejjednodussi 
< napsat tridu, vyhradne pres kterou se bude pristupovat k DB a tu tridu 
< udelat singelton. Threadsafe zarucite na urovni tohoto singeltona. Bude 
< to asi pomalejsi, nez kdyby to delala sama DB, teda pokud ten sigelton 
< nejak sofistikovane nepoladite.

Neni mi jasne, jak by tohle melo fungovat, protoze i kdyz k databazi budu
pristupovat vyhradne pomoci jednoho objektu, tak, kdyz jeho metody budou
volany z ruznych threadu, a pobezi v jejich kontextu. A mel-li jsem
podminku, ze spojeni nesmi byt sdileno mezi thready, tak to imho muj
problem neresi. A nebo neco hrube nechapu.
 
< Jine reseni je, ze pokud pri zapisu nemuze vzniknout nejaky zasadni 
< problem, muze server pracovat davkove, tj. prevzit pozadavek od klienta 
< a pak data v klidu ulozit do DB, az bude mit cas. Cteni bude stejne asi 
< blokovaci (jen se muzete rozhodnout, zda bude vyrizeno prednostne pred 
< cekajicimi zapisy nebo pocka, az se zapisou vsechny cekajici data).

Ano, o necem takovem jsem uvazoval, server by mel frontu, do ktere by 
komunikacni thready ukladaly pozadavky a jeden thread obsluhujici databazi
by je vyrizoval. Pro ukladani dat by to bylo skvele, ale ri cteni dat bych
musel resit, jak nactena data predat prislusnemu threadu, ktery by je pak
vratil klientovi a to uz se mi zdalo moc komplikovane, skvela prilezitost
k rade nahodnych tezko detekovatelnych chyb a tak se mi do toho nechtelo.
 
< Nicmene nez bych se do neceho takoveho poustel, zkusil bych, jak 
< skutecne klienty zpomaluje, ze server muze obslouzit jen jednoho klienta.

Ona je skutecnost trochu slozitejsi, klientu bude vic druhu, nektere 
vylozene zadavaci, ty data budou prevazne zadavat, pak monitorovaci, ty
je zas budou prevazne cist, pak ridici jednotka pro nastaveni a vladani
systemu, vkladani prvoznich dat a podobne, dale bych mel data predavat do 
jakehosi jiz existujiciho vizualizacniho systemu, o cemz zatim sam moc nevim, 
jednani o komunikaci s jeho tvurci me teprve ceka, a tak. Tedy klasicky zber,
zpracovani, ukladani a opetovna distribuce dat. Pouziti threadu se mi zda 
jednodussi, kdyz vyresim ukladani a to uz jsem vyresil.


< Co se tyce vice vlaken v DB, nepropadal bych zbytecnemu optimizmu. 
< Nevim, jak zamyka MySQL, ale docela casto DB zamykaji na urovni tabulek. 
< Specialne pokud mate castejsi zapis nez cteni, budou thready cekat, az 
< to ten slimak pred nima dodela a tabulku jim uvolni. Navic ono ani 
< takovy zamykani neni uplne zadarmo, takze pokud zapisujete mala data, 
< muze rezie vice vlaken delat bez problemu i 90% casu.

Jak jsem psal, nevadi mi, kdyz k databazi bude moci pristupovat v jednu 
chvili jen jeden thread, takze ani zamykani tabulek by me netrapilo, neni 
to hlavni napln toho serveru. Odhaduji, ze zapisy budou provadeny radove
ve vterinovem intervalu, v kratkodobe spicce cca 5 zapisu za vterinu,
SQLite jich zvladne nekolik tisic za vterinu.

Petr Mach
____________________________________________________________
http://www.bezpecnyinternet.cz
http://ad.seznam.cz/clickthru?spotId=94734