Witam.

Mam dziwny problem z destruktorami i nie za bardzo wiem jak go rozwiązać. Przeglądałem trochę forum i manuala, ale nic w podobnym stylu nie było.

Oto opis mojego problemu: mam prosty systemik, w którym mam m. in. klasy DB (obsługa bazy danych, śle zapytania i przechowuje informacje o ewentualnych błędach) oraz Session (jak sama nazwa mówi - do obsługi sesji).

W klasie Session w destruktorze wywołuję metodę, która kończy mi daną sesję, czyli przy pomocy klasy DB robi UPDATE danych w bazie. Działa, jednak...no właśnie. Gdybym w klasie DB miał destruktor, w którym kończyłbym połączenie z bazą danych, to to zapytanie już wygeneruje błąd, czyli tak jakbym był rozłączony. Dodam jeszcze, że później pobieram sobie pewną metodą informacje o zapytaniach (klasa DB) i brakuje tego ostatniego zapytania kończącego sesję (teraz oczywiście rozważam wersję bez zakończonego połączenia).

Aha, jeszcze dodam (może to mieć jakiś związek - tak przypuszczam), że obiekty pobieram przy pomocy czegoś w stylu rejestru, tzw. ClassLoader'a.
Załączę odnośniki do kodów klas. Na logikę i angielski proszę na razie nie zwracać uwagi - poprawki wprowadzam na bieżąco
session.class.php
db.class.php
classloader.class.php

Jaki jest sens zamykania połączenia z bazą danych w destrukorze klasy Db? Wg mnie nie ma żadnego sensu, bo tak czy siak połączenie z bd jest zamykane na końcu działania aplikacji.

Też racja.

Ale nawet nie o to mi chodziło. Chciałbym uzyskać odpowiedź na temat tego destruktora, dlaczego to nie działa. W sumie jakoś pracy szczególnie nie utrudnia, ale bywa w małym stopniu irytujące, gdyż (moim zdaniem) powinno wszystko działać.

Przez lata programiści nauczyli się nie ufać destruktorom w PHP. Sprawiały mnóstwo problemów (wystarczy poczytać komentarze w odpowiednim rozdziale manuala). Istnieje obejście tego problemu, dosyć szeroko stosowane w wielu frameworkach - swój własny wirtualny system zarządzania obiektami.

[PHP] pobierz, plaintext 
class ApplicationManager
{
    protected $managers = array();
 
    public function registerManager(IManager $manager)
    {
        $this->managers[] = $manager;
    }
 
    public function start()
    {
        // number of registered managers
        $norm= count($this->managers);
        for($i = 0; $i < $norm; $i--)
        {
            $this->managers[$i]->start();
        }
    }
 
    public function stop()
    {
        // number of registered managers
        $norm= count($this->managers);
        for($i = $norm - 1; $i >= 0; $i--)
        {
            $this->managers[$i]->stop();
        }
    }
}
 
interface IManager
{
    public function start();
    public function stop();
}
 
class SessionManager implements IManager
{
    public function start()
    {
        // ustawiasz sobie sterownik sesji 
    }
 
    public function stop()
    {
       //zamykasz sesję
    }
}
 
 
class DatabaseManager implements IManager
{
    public function __construct($dsn)
    {
         // łączysz się z bazą
    }
 
    public function start() {}
 
    public function stop()
    {
       // zamykasz połączenie z bazą
    }
}
[PHP] pobierz, plaintext 

A wykorzystujesz to mniej więcej tak.

[PHP] pobierz, plaintext 
$application = new ApplicationManager();
 
// dalej pobierasz konfig aplikacji i tworzysz na jego podstawie potrzebne obiekty m.in. obiekty odpowiedzialne za sesje i połączenie z bazą danych.
 
$database = new Database($config['database']['dsn']);
 
$application->registerManager($database);
 
$session = new SessionManager();
 
$application->registerManager($session);
 
$application->start(); // wszystkie zarejestrowane obiekty wykonują własne metody start()
 
// etc
 
$application->stop(); // wszystkie zarejestrowane obiekty wykonują własne metody stop(). Zwróć uwagę, że robią to w odwrotnej kolejności niż zostały zarejestrowane. To jest ważne - pozwala zachować zależności.
 
[PHP] pobierz, plaintext 

Wszystko pisane z palca, więc jakby co poprawiać lub pytać

Pozdrawiam



O ile sam nie usuwasz obiektów robi to samo PHP przy zakończeniu skryptu - a wtedy nie możesz być 100%-owo pewny kolejności. Rozwiązanie powyżej.

Mylisz się. Połączenie jest zamykane w chwili jego wygaśnięcia, czyli wcale niekoniecznie po zakończeniu działania aplikacji. Timeout jest ustawiany w opcjach MySQL.

Jeśli odwiedzalność Twojej strony jest na poziomie 1/godzinę, to nie ma to znaczenia. Ale jeśli chcesz stworzyć optymalny skrypt, który wytrzyma obciążenie rzędu kilkuset - kilka tys. odsłon / minutę, to oczekiwanie na wygaśnięcie każdego połączenia nie jest dobrym pomysłem.

Więc chyba przebuduję swoją aplikacyjkę, wywalę destruktory i zastąpię to tym (nieco zmienionym - mam chyba pomysł) rozwiązaniem. Czytałem sporo o tych destruktorach i faktycznie pojawiło się trochę informacji o "wałkach" jakie robią. Myślałem, że dotyczyły one wersji PHP <=5.1, a tu proszę.

Dziękuję za rzeczowe uwagi.

dodałem kilk małych zmian w kodzie.



Oczywiście, musisz to zmienić, żeby było używalne. To co przedstawiłem to jedynie zalążek

Nie wiem czy masz rację, ale moją wiedzę na ten temat zaczerpnąłem z manuala, być może jest tam błąd lub nowsze biblioteki do obsługi baz danych różnią się pod tym względem.

http://pl.php.net/mysql_close
http://pl.php.net/pg_close

Jednak nie znalazłem informacji jak to wygląda np. w mysqli czy PDO, być może jest tak jak mówisz. Oczywiście mówimy tutaj o połączeniach tymczasowych, a nie stałych, które to na pewno nie są zamykane wraz z końcem działania aplikacji.

Wygaśnięcia, to znaczy? Bo pierwsze słyszę o wygasaniu połączeń...


W sterownikach stricte obiektowych jest to realizowane właśnie w destruktorach.

@-=Peter=-, @erix,
oczywiście macie rację. Strasznie nabredziłem.
Jednak dalej jestem przekonany do zamykania połączenia w destruktorze.

@erix,
usuń proszę mojego poprzedniego posta, albo przekreśl jego treść - niech nie miesza ludziom w głowie. Ja już nie mogę edytować.

Zrobione. Na przyszłość raportuj.


Wiesz, kiedyś działy mi się dziwne rzeczy, jeśli używałem mysql_free_result w destruktorze. Nie mam zielonego pojęcia, czemu to się tak działo; może w ostatnich wersjach zostało to poprawione, trudno mi cokolwiek na ten temat powiedzieć.