Jakie mam inne rozwiązanie tego problemu?
Użyj LISTEN i NOTIFY aby poinformować aplikację, że coś się zmieniło.
Możesz wysłać NOTIFY z wyzwalacza, który rejestruje również zmiany w tabeli kolejki.
Będziesz potrzebować połączenia PgJDBC, które wysłało LISTEN dla wydarzeń, z których korzystasz. Musi odpytywać bazę danych, wysyłając okresowe puste zapytania ("" ), jeśli używasz SSL; jeśli nie używasz SSL, można tego uniknąć, korzystając z kontroli powiadomień asynchronicznych. Musisz rozpakować Connection obiekt z puli połączeń, aby móc rzutować podstawowe połączenie na PgConnection do korzystania z funkcji nasłuchiwania/powiadamiania. Zobacz pokrewną odpowiedź
Bit producent/konsument będzie trudniejszy. Aby mieć wielu jednoczesnych konsumentów odpornych na awarie w PostgreSQL, musisz użyć blokowania doradczego z pg_try_advisory_lock(...) . Jeśli nie potrzebujesz jednoczesnych konsumentów, to jest to łatwe, po prostu SELECT ... LIMIT 1 FOR UPDATE wiersz na raz.
Mam nadzieję, że 9.4 będzie zawierał łatwiejszą metodę pomijania zablokowanych wierszy za pomocą FOR UPDATE , ponieważ trwają prace nad tym rozwojem.
