Ostatní témata (Off Topic témata) : phpRS Fórum
Máte problém s konfigurací počítače? Hledáte nejlepší webhosting pro vaši aplikaci? Nevíte si rady s nějakým zajímavým programátorským oříškem? Týká se dotaz fóra? ... Pokud ano, tak je toto diskuzní fórum určeno právě vám.
phpRS - redakční a informační systém
použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: Kryšpín (IP adresa zaznamenána)
Datum: 2005-05-17, 23:16

Zdravím
zkoušel jsem použít tuhle funkci, zamknutí tabulek, když jich upravuju více. Není to pro mě prozatím nic naprosto nezbytného, ale jsou místa, kde si myslím, by se to hodilo. Jenže při ladění jsem zjistil nepříjemnou věc: když se v kodu mezi LOCK a UNLOCK objeví nějaká fatální chyba tak to blokne kompet server MySQL (o data nepřijdu, ale na lokále v ten moment přestane chodit celý MySQL server a musí se restartovat.)

Čímž pádem jsem to zatím raději v kodu zakomentoval. (úpravy intfora v nové verzi). Nicméně jsem měl představu takového "servisního skriptu na přepis databáze" Nevím jeslti to nakonec nevyřeším jinak, ale kdybych tohle někdy potřeboval, jak to použít aniž bych případně sundal celý nějaký hosting. To by asi jen tak neprošlo. :-D

Chápu, že nejlepší by bylo neudělat v tom kodu žádnou chybu. Ale v případě takovýhle následků bych se bál snad i prázdnýho místa mezi těmito dvěma příkazy.

Nebo je to tím, že mám špatně nakonfigurovaný MySQL (to je taky možnost, protože jsem to vlastně nechla v nějaké distribuční podobě).

Jinak už jsem to zkoušel dříve a měl jsem s tím problém i takový, že když jsem zamknul tabulku "A" tak funkce zavolaná z jíného místa skriptu, která potřebovala pracovat s jinou tabulkou, dejme tomu "B" taky nefungovala.

už jsem z toho (td):-(

nevyznáte se v tom někdo více?
díky

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: JanVar (IP adresa zaznamenána)
Datum: 2005-05-18, 01:58

LOCK TABLES main_table READ => pouze ke cteni
LOCK TABLES main_table WRITE => sesna, ktera prvni zamkla, ma pravo cist a zapisovat, ostatni pouze cist

jinak si testovat pomocnou promennou, kterou budes v kazdem radne ukoncenem cylku nulovat. Pokud je "RETURN 0", pak je vse OK a lze provest UNLOCK. Pokud je vsak "RETURN 1" tak okamzite vyskocit z cyklu a provest UNLOCK.

BTW MySQL uz take pouziva transakcni zpracovani, tak ze spise asi zalezi, co od toho potrebujes.... Pokud jen konsistentni zalohu DB, melo by stacit testovat pouze tu navratovou hodnotu

-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: pa3k (IP adresa zaznamenána)
Datum: 2005-05-18, 09:45

transakcie nepomozu?
pár príkladov použitia by malo byť v mauály:
[http://sk.php.net/manual-lookup.php?pattern=SQL%2Btransaction&lang=sk]
[http://sk.php.net/manual/sk/function.pdo-begintransaction.php]



Celkem upraveno 1×. Poslední úprava pa3k v 18.05.2005 09:59.

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: Kryšpín (IP adresa zaznamenána)
Datum: 2005-05-18, 14:56

ono to bylo asi takhle:

1.--> .... LOCK TABLES jmeno_tabulky WRITE .....

2.--> pak nějaké příkazy

3.--> .... UNLOCK TABLES


No a když v té části kde jsou ty příkazy je nějaká chyba, na které skript umře, tak je v ten moment celý MySQL server v háji. (lze to nasimulovat například tím, že tam vložíte příkaz die(); nebo exit(); či něco takového, ale prvně se mi to podařilo nějakou chybou v mysql příkazu. :-)

Pak přestane celá ta legrace fungovat a objeví se: systém nemůže najít potřebné databázové tabulky. Dokonce to zrušilo všechny databáze naráz. (tedy zrušilo, ne data, ale server, po restartu mysql bylo vše OK) Zkusil jsem jiným prohlížečem otevřít jinou instanci phpRS na jiné databázi a bylo to to samé.

Jinak byl to jen nedůležitý experiment, při vkládání příspěvků do fora je asi malá pravděpodobnost, že by se dva příkazy vkládaly v tu samou milisekundu, takže to tam nepotřebuju. Ale pro jiné účely by se mi to hodilo, ne




Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: pa3k (IP adresa zaznamenána)
Datum: 2005-05-18, 16:39

Nie som expert na MySQL ale myslím, že práve transakcia by tu mohla pomôcť, pretože v prípade výskytu SQL chyby by mal pomôcť rollback. Dávka dotazov ktorá by v prípade chyby niektorého z nich spôsobila nekonzistenciu dát, pustíš v transakcii. Ak bude chyba, vrátiš to tým rollbackom, nie?
<?php
/* Begin a transaction, turning off autocommit */
$dbh->beginTransaction();

/* Change the database schema and data */
$sth = $dbh->exec("DROP TABLE fruit");
$sth = $dbh->exec("UPDATE dessert
   SET name = 'hamburger'");

/* Recognize mistake and roll back changes */
$dbh->rollBack();

/* Database connection is now back in autocommit mode */
?>


citujem z SQL fora na builder.cz:
[http://forum.builder.cz/read.php?21,235475,235475#msg-235475]
-----------8<-----------------
Co takhle zkusit zpracování v transakci.
Neznám přesně syntaxi MySQL, ale mělo by to být přibližně takto
BEGIN WORK;
LOCK TABLE ...
LOCK TABLE ...
UPDATE ..., DELETE ..., INSERT ...
...
ROLLBACK pokud se to nepovede
COMMIT pokud je O.K.
Zkuste najít přesnou syntaxi v dokumentaci.

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: JanVar (IP adresa zaznamenána)
Datum: 2005-05-18, 17:36

no ja pochopil, ze Kryspin chce jen zamknou DB kvuli zaloze...
IMHO transakce jsou pochopitelne na neco uplne jineho. Transakcni zpracovani se pouziva napriklad a hlavne u bankovnich prevodu. Pokud neprojde cely dotaz, tak se potom dela ROLLBACK.

pro tu zalohu bych sel prez pomocnou promennou..

To: Kryspin...
misto DIE pouzij napred ten UNLOCK.. Pak muzes testovat ten zbytek...

BTW vecer budu na ICQ...


-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: pa3k (IP adresa zaznamenána)
Datum: 2005-05-18, 18:15

Novšie verzie phpMyAdmina (2.6.2 určite) majú možnosť pri exporte databázy uzatvoriť príkazy v transakcii, to by IMHO malo stačiť. Keď treba - môžeš pozrieť do zdrojákov.

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: JanVar (IP adresa zaznamenána)
Datum: 2005-05-18, 18:29

To: pa3k...
ale tady nejde o phpadmina. tady zrejme pujde o plugin, ktery si zamkne DB pro sebe... (tedy alespon tak jsem to pochopil)...

no pockame na Kryspina

-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: pa3k (IP adresa zaznamenána)
Datum: 2005-05-18, 23:50

> MHO transakce jsou pochopitelne na neco uplne jineho. Transakcni zpracovani se pouziva napriklad a hlavne u bankovnich prevodu. Pokud neprojde cely dotaz, tak se potom dela ROLLBACK.

malý OT:
Transakcie chápem inak. Dotazy v rámci transakcie by mali byť spracované tak aby pri behu transakcie nemohlo byť spracovávané ďalšie vlákno. Príklad: jeden update dotaz zvýši platy zamestnancom o +10% a súčasne v inom vlákne bude spracovávaný iný, ktoý triedi zamestnancov podľa platu. Ak pobežia naraz môže dôjsť k chybe vo výpočte. Preto zvýšim platy pomocou transakcie a tým zabezpečím, že do skončenia transakcie nepobeží iné vlákno. No a to mi príde použiteľné aj pri tej zálohe. Ak sa mýlim opravte ma. :)

SET AUTOCOMMIT=0;
START TRANSACTION;
:
: tu bude hafo dotazov
:
COMMIT;

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: pa3k (IP adresa zaznamenána)
Datum: 2005-05-18, 23:57

Krišpín, skús mi poslať ten kód na testing. Locknutie tabuliek by predsa nemalo zhodiť celé MySQL. Skusil by som to otestovať u mňa, prípadne na rôznych verziách MySQL.

Re: použití LOCK TABLES, UNLOC.. nevyznáte se někdo trochu více?
Zaslán uživatelem/kou: JanVar (IP adresa zaznamenána)
Datum: 2005-05-19, 00:21

pa3k napsal/a:
-------------------------------------------------------
> > Transakcni zpracovani se pouziva napriklad a hlavne u bankovnich prevodu. Pokud neprojde cely dotaz, tak se potom dela ROLLBACK.
>
> malý OT: Transakcie chápem inak. Dotazy v rámci transakcie by mali byť spracované tak aby pri behu transakcie
> nemohlo byť spracovávané ďalšie vlákno. Príklad:
> jeden update dotaz zvýši platy zamestnancom o +10% a súčasne v inom vlákne bude spracovávaný iný,
> ktoý triedi zamestnancov podľa platu. Ak pobežia naraz môže dôjsť k chybe vo výpočte. Preto zvýšim
> platy pomocou transakcie a tým zabezpečím, že do skončenia transakcie nepobeží iné vlákno. No a to
> mi príde použiteľné aj pri tej zálohe. Ak sa mýlim opravte ma.

je to sice dobra myslenka, ale TRANSAKCE jsou skutecne mysleny tak, jak jsem uvedl....
proste pokud neprojde cely SQL, tak se potom provadi ROLLBACK... Pripadne se daji naplnit promenne a pak provest nejaky SQL nad DB (vyhradni zapisovy rezim)....

Je pochopitelne, ze vetsinou ten, kdo si LOCKne (desne slovo.. :-) ) DB pro sebe, ma potom prava vyhradni, a ostatni musi pockat, ale uz sam nazev napovida, o cem to je....

BTW proto ma LOCK dva rezimy READ a WRITE. Pokud si zamknu DB jako WRITE, pak k ni mam vyhradni pravo a ostatni musi pockat. Mohou pouze cist, nikoliv zapisovat.
( je to ode mne hodne zjednodusene vysvetleni... )

EDIT:
> jeden update dotaz zvýši platy zamestnancom o +10% a súčasne v inom vlákne bude spracovávaný iný,
> ktoý triedi zamestnancov podľa platu.

tady pozor!!!
jeden dotaz je "updade" a dalsi je "select"...

pri "update" neni potreba DB zamykat. to je osetreno samo o sobe... navic, "select" jen <<cte>> data, tudiz je nemeni...
Zamykani se pouziva, pokud potrebuji DB <<pouze a vyhradne>> pro sebe... Pokusim se to uvest na <<pravou miru>>

Kazda DB umoznuje provadet zapis a menit data nad "vetou". A kdyz se nahodou setkaji dva soucasne pozadavky "nad jednou vetou", tak pochopitelne <<vyhrava>> ten posledni, ktery uklada...

No snad jsem to vysvetlil srozumitelne.... pokud ne, tak se omlouvam....

A proto se pouziva zamykani DB...

-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------



Celkem upraveno 1×. Poslední úprava JanVar v 20.05.2005 23:22.



Lituji, ale pouze registrovaní uživatelé mohou zasílat příspěvky do této sekce.
This forum powered by Phorum and designed by STaNBoSS.