Mm pytanie dotyczące obsługi transakcji w mysql. Do tej pory korzystałem z nich czasem w ramach pojedynczego wywołania skryptu php na zasadzie:
1. połącz z bazą
2. START TRANSACTION
3. seria selectów i update'ów
4. jak wszystko ok to COMMIT

a co jeśli chciałbym aby transakcja była podtrzymywana w czasie kilku wywołań skryptu php? czy jest to możliwe? Chodzi o to żeby po zakończeniu skryptu php połączenie nie było zrywane z nastepstwem ROLLBACK tylko aby kolejne wywołanie skryptu mogło nadal działać w ramach tej samej transakcji. Funkcja mysql_pconnect() ma niby podtrzymywać połączenie z bazą - jak dla mnie na razie działa identycznie jak mysql_connect(). Może trzeba coś skonfigurować? Oczywiscie tabele innodb.

Przyznam, ze nigdy nie uzywalem pconnect i nie wiem czy to w ten sposob zadziala, ale jak dla mnie to nie powinienes zastepowac "logiki biznesowej" transakcyjnoscia. Transakcja dziala w ramach unit-of-work a to co Ty chcesz zrobic to juz jest wiele unit-of-work. Napisz moze co chcesz osiagnac. Sama funkcja pconnect z tego co widze, jest mocno ryzykowna.

Nie wiem, czy to logika biznesowa, dla mnie to zagadnienie czysto bazodanowe. Chodzi mi o zachowanie spójności danych modyfikowanych przez różnych użytkowników. Mam rekord w tabeli. Nagle dwóch uzytkowników wybiera z niego dane i wyświetla w formularzu edycji.
Jeden zapisuje formularz - następuje update tabeli, a zaraz potem drugi uzytkownik robi to samo i dane pierwszego użytkownika w nalepszym wypadku zostają nadpisane przez drugiego. Gdyby pobraniu rekordu przez pierwszego usera towarzyszyło rozpoczecie transakcji rekord zostałby zablokowany dla pozostałych dopóki uzytkownik nie zwróci danych z formularza i nie nastapi COMMIT albo ROLLBACK . Dopiero wtedy inni uzytkownicy będą mić dostep do tego rekordu ale ujrzą aktualne. Tak dzieje się w aplikacjach klienckich baz danych. Mniejsza o to czy zrobić to samymi transakcjami czy poprzez "lock tables" ale wazne aby pomiędzy poszczególnymi przeładowaniami skryptu została zachowana integralna całość procesu. Po prostu uzytkownicy nadpisują sobie wzajemnie dane do których mają dostęp.

Mysle, ze odpowiedni poziom izolacji zapytan rozwiaze problem z jednoczesnym pobieraniem i updatowaniem przez rozne procesy. Gorzej jesli jakies dane maja byc wczytane do formularza i moga sobie wisiec przez x minut a nastepnie beda zatwierdzone. Tutaj chyba nie obejdzie sie bez zmiany statusu z jakims czasem rezerwacji rekordu tabeli na wylacznosc. To juz jednak jest logika biznesowa. Rozumiem teraz o co chodzilo wczesniej. Ja bym tego na transakcje nie zrzucal nawet jesli sie da. Kiedy mialby byc zrobiony commit? Do tego dane po edycji by byly... nieaktualne bo de facto niezacommitowane.

Nie powinieneś robić tego w ten sposób. Dodaj sobie w bazie danych kolumnę z czasem ostatniej aktualizacji. Następnie w formularzu edycji wrzuć do ukrytego pola czy tam jako zmienną sesynją tą datę - tak by była ona przesłana do skryptu odpowiedzialnego za wykonanie zapytania UPDATE. Na koniec w skrypcie modyfikującym bazę danych dodaj na początku sprawdzenie czy przesłana data jest równa tej w bazie danych. Jeśli tak, oznacza to że rekord nie został zmodyfikowany w czasie od wyświetlenia formularza do jego wsyłania. Jeżeli zaś jest inna pzekieruj użytkownika spowrotem do formularza edycji i informacją o tym, że rekord został przez kogoś zaktualizowany.

Heh doszedłem do takich samych wniosków :/ ale coś mnie podkusiło z tymi transakcjami Dzięki za pomoc!