Hibernate - nasłuchiwanie zmian w bazie

Witam.

Chciałbym się dowiedzieć czy istnieje jakiś prosty sposób do sprawdzenia czy w bazie zaszły jakieś aktualizacje (usunięcie, aktualizacja, dodanie rekordu do i z tabeli)
Czy hibernate udostępnia jakieś metody nasłuchu?
Odpytywanie o zmiany nie jest zbyt ciekawym rozwiązaniem.
Ewentualne jakieś trigger'y.

Pozdrawiam.

@caprio: da się zrobić Listenery na zdarzenia związane z Hibernatem tak jak tutaj: https://www.boraji.com/hibernate-5-event-listener-example. Ale nie znam żadnej możliwości żeby sam Hibernate nasłuchiwał bezpośrednio BD

posłuchaj @hcubyc i nie idź tą drogą

W architekturze z więcej niż jednym klientem śledzenie zmian w bazie będzie trudne. Teoretycznie dałoby się coś skręcić, jakieś tam triggery na on update + wywoływanie zewnętrznego serwisu, w praktyce - nie chcesz tego robić. Poszukaj raczej rozwiązań takich jak Apache Kafka.

A serwer pośredniczący pomiędzy kilkoma klientami i bazą wchodzi w grę?

Jak chcesz temat od strony baz ugryźć, to jest to możliwe . Słowa klucze: "Change Data Capture". Tyle, że to temat rzeka.

Do tego na bazach "enterprajzowych" masz możliwość tworzenia kolejek i publikowania w nich zmian za pomocą triggerów.
Do takich kolejek mogą się podpinać zainteresowane aplikacje. Możesz mieć więc model "publish-subsribe point-2-point".

W jakim celu chcesz tego używać?

Do integracji jest to średni pomysł, bo możesz mieć te same dane i 2 istotnie różne scenariusze, które generują tę samą zmianę (np. nowa umowa vs cesja umowy - w obydwu przypadkach pojawią Ci się nowe umowy) albo (płatność vs wycofanie płatności - saldo się zmieni). Jednak patrząc tylko na dane, to zgubisz trochę informacji, albo Twój proces wykrywania zmian będzie się rozrastał i będzie trudny w utrzymaniu.

Chodzi o jak najszybsze poinformowanie klientów, że jeden z nich zmienił dane w bazie (dodał, zmodyfikował, usunął rekord w tabeli).

Jeśli twoi klienci bezpośrednio wszyscy grzebią w bazie i nie da się tego zmienić to:

1. popłacz 5 minut nad swoją architekturą, to i tak j..nie,
2. Zainteresuj sie kafka confluent

Jeśli można archiekturę zmienić to klasycznie: dostep do bazy zakryj serwisem web( serwer posredniczący). A do informowania klientów użyj jakiegos messagingu: kafka, activemq, websockets, sse. Zależy co pasuje.

Stworzyłem serwer pośredniczący, do którego klienci wysyłają żądania CRUD a on operuje na bazie, jednocześnie powiadamiając pozostałych klientów o zmianach w danym rekordzie. Jeśli ktoś dodaje rekord, zostają powiadomieni o tym inni i odświeżają dane. Jeśli ktoś modyfikuje dane inni tracą taką możliwość w stosunku do danego rekordu. Serwer co minutę odpytuje klientów czy "żyją". Jeśli tak a edycja trwa więcej niż 5 minut rekord zostaje automatycznie odblokowany. Wydaje mi się, że to jedyne najszybsze i najbezpieczniejsze rozwiązanie. Serwer i klienci komunikują się za pomocą gniazd, wykorzystując nieblokujące połączenia.
Kiedyś napisałem program kliencki niewymagający serwera. Klienci operowali bezpośrednio na bazie danych. Każda tabela posiadała kolumnę edit, do której swoją nazwę zapisywał każdy użytkownik, który edytował dany rekord a po zakończeniu ustawiał jej wartość na "no" (typ char). Inni rozpoznawali po tym czy możliwe są operacje na nim. Każda modyfikacja zostawała zapisywana do specjalnej tabeli zawierającą nazwę tabeli i id rekordu oraz nazwą użytkownika. Klient sprawdzał za pomocą Timer'a (co 5 sek) czy id tej tabeli wzrosło, jeśli tak odczytywał wartości i uzyskiwał w ten sposób informację co się dzieje. A dalej już wiadomo. Niestety takie podejście jest dość niechlujne, powolne i mimo wszystko niebezpieczne dla danych.

caprio napisał(a):

Stworzyłem serwer pośredniczący, do którego klienci wysyłają żądania CRUD a on operuje na bazie, jednocześnie powiadamiając pozostałych klientów o zmianach w danym rekordzie. Jeśli ktoś dodaje rekord, zostają powiadomieni o tym inni i odświeżają dane. Jeśli ktoś modyfikuje dane inni tracą taką możliwość w stosunku do danego rekordu. Serwer co minutę odpytuje klientów czy "żyją". Jeśli tak a edycja trwa więcej niż 5 minut rekord zostaje automatycznie odblokowany. Wydaje mi się, że to jedyne najszybsze i najbezpieczniejsze rozwiązanie. Serwer i klienci komunikują się za pomocą gniazd, wykorzystując nieblokujące połączenia.
Kiedyś napisałem program kliencki niewymagający serwera. Klienci operowali bezpośrednio na bazie danych. Każda tabela posiadała kolumnę edit, do której swoją nazwę zapisywał każdy użytkownik, który edytował dany rekord a po zakończeniu ustawiał jej wartość na "no" (typ char). Inni rozpoznawali po tym czy możliwe są operacje na nim. Każda modyfikacja zostawała zapisywana do specjalnej tabeli zawierającą nazwę tabeli i id rekordu oraz nazwą użytkownika. Klient sprawdzał za pomocą Timer'a (co 5 sek) czy id tej tabeli wzrosło, jeśli tak odczytywał wartości i uzyskiwał w ten sposób informację co się dzieje. A dalej już wiadomo. Niestety takie podejście jest dość niechlujne, powolne i mimo wszystko niebezpieczne dla danych.

Tu jest nie jeden, ale kilka antywzorców i morderstwo zasobów zamiast porządnej inżynierii.

W dodatku wykazałeś niewiedzę o lepszych rozwiązaniach 1), które zastępujesz gorszymi "jak się małemu Jasiowi wydawało".
Dalej będziesz, jak socjalizm, dzielnie rozwiązywał problemy nieznane w innych projektach

1. np optimistic locking (już pominę, że mogłeś go wykorzystać) zostawia w bazie timestamp/version

PS. Też jestem za kolejkami komunikatów, O ILE nadal będzie je potrzebował.

caprio napisał(a):

Chodzi o jak najszybsze poinformowanie klientów, że jeden z nich zmienił dane w bazie (dodał, zmodyfikował, usunął rekord w tabeli).

Po co "jak najszybsze", jeśli nie wiadomo czy klient w ogóle jest danymi zainteresowany?

caprio napisał(a):

Chodzi o jak najszybsze poinformowanie klientów, że jeden z nich zmienił dane w bazie (dodał, zmodyfikował, usunął rekord w tabeli).

To chyba podpada pod klasyczne MVC jakie było w Smalltalku. Ale mało kto pisze tak aplikacje webowych/sieciowych bo jest to zbyt problematyczne. Co najwyżej invaliduje się lokalne cache. A klient jest powiadamiany od tym że dane się zmieniły dopiero jak robi nowy request

A może wystarczy Ci po prostu optimistic locking, żeby odbić niepoprawny zapis i zapobiec nadpisywaniu zmian?.

Jeżeli rzeczywiście zależy Ci na aktywnym powiadamianiu klientów, że coś się zmieniło (jak np. w czacie). Możesz zrobić tak, to nie jest wielka filozofia, ale dokłada Ci trochę infrastruktury:
klient B subskrybuje się na zmiany na zasobie -> klienta A modyfikuje zasób -> zapisujesz zmiany -> wysyłasz event ze zmianami, jakie zaszły -> klient B dostaje event. Do tego potrzebujesz websocket, SSE albo HTTP/2 server push. Ewentualnie może na MVP wystarczy long polling.