Quelle autre solution ai-je à ce problème ?
Utilisez LISTEN et NOTIFY pour dire à votre application que les choses ont changé.
Vous pouvez envoyer le NOTIFY à partir d'un déclencheur qui enregistre également les modifications dans une table de file d'attente.
Vous aurez besoin d'une connexion PgJDBC qui a envoyé un LISTEN pour le ou les événements que vous utilisez. Il doit interroger la base de données en envoyant périodiquement des requêtes vides ("" ) si vous utilisez SSL ; si vous n'utilisez pas SSL, cela peut être évité en utilisant les contrôles de notification asynchrone. Vous devrez déballer la Connection objet de votre pool de connexion pour pouvoir convertir la connexion sous-jacente en un PgConnection utiliser écouter/notifier avec. Voir la réponse associée
Le bit producteur/consommateur sera plus dur. Pour avoir plusieurs consommateurs simultanés à l'abri des pannes dans PostgreSQL, vous devez utiliser le verrouillage consultatif avec pg_try_advisory_lock(...) . Si vous n'avez pas besoin de consommateurs simultanés, c'est simple, il vous suffit de SELECT ... LIMIT 1 FOR UPDATE une ligne à la fois.
Espérons que 9.4 inclura une méthode plus simple pour ignorer les lignes verrouillées avec FOR UPDATE , car il y a du travail de développement pour cela.
