taak, i w ten sposób zasracie serwery http i bazy danych. nie dość, że kilkadziesiąt i więcej naraz przetwarzanych requestów wydoi całą pamięć z serwera, to pętla while bez żadnego sleepa w środku zużyje 100% procesora (co prawda samo zapytanie będzie działać jako sleep, ale wtedy baza danych będzie kontynuować obciążanie procesora), a ciągłe zapytania do bazy danych zamordują także i ją; a jeśli baza danych stoi na osobnym serwerze, to jeszcze i przytkacie nieco sieć (aczkolwiek w dobie gigabitowych sieci lan to chyba będzie najmniejszy problem).
imho pomysł ciekawy, ale tylko do bardzo specyficznych zastosowań i tylko po solidnej optymalizacji.
Muszę sprostować.
Bynajmniej nie miałem na myśli ciągłego zapytywania bazy danych w wątku. Wątek czeka grzecznie, ale praktycznie nie robi nic - do momentu, aż dostanie notyfikację. Notyfikacja musi być obsługiwana przez warstwę biznesową (nie wiem jak to zrobić w php - nie znam tego języka), widziałem świetnie działające implementacje w .NET.
To właśnie warstwa pośrednia (czyli praktycznie kod serwisu) jest odpowiedzialny za wysłanie notyfikacji : dodano komentarz pod obrazkiem numer xxxx" (pseudo). Zainteresowane wątki sprawdzą sobie, czy interesuje ich obrazek xxxx, wtedy kończą wątek i nowy komentarz wraca do klienta. Ten znowu odpala zapytanie....
Tak więc wątek nie robi praktycznie nic, do momentu notyfikacji lub timeoutu (żadnego ciągłego czytania w bazie lub co jakiś interval!). Notyfikację można zrealizować przez wewnętrzny event w serwisie wysyłany w razie potrzeby. W naszym przykładzie - będzie to moment dodania nowego komentarza - dodajemy event, które notyfikuje zainteresowane komponenty, że dodano nowy komentarz (wraz z informacją kto, gdzie, co).
Dodatkowo, każdą notyfikację należy opatrzyć w unikalny numer, inkrementowany za każdym razem. W ten sposób wątki będą mogły ustalić dolny zakres notyfikacji, jakie chcą otrzymywać. Dzięki temu, nie stracimy żadnej notyfikacji w czasie, gdy klient wykonał "przerwanie".