Przechowywanie prostego stanu w pliku

Musze przechować ostatni response id ( long ) w pliku. Tak zostało zaprojektowane api z którym się integruje że potem musze tego response id przekazać w innych wywołaniu. Ale to inny temat.
Obecnie mam dwa rozwiązania:

1. własną implementacje przy użyciu java.io
2. implementacja w oparciu o jdbm - https://jdbm.sourceforge.net/ - staroć ale dziala ok ( nowa wersja https://github.com/jankotek/mapdb )

Może ktoś polecić coś innego ( lepszego ) , jakąś prostą biblioteke java które pozwala zarządzać stanem ?

Trochę mało informacji. Gdzie ten response Id jest nadawany?
Przedstawiłeś problem tak jakbyś chciał longa zapisać w jakiejś bazie po to by go potem wyciagnąć i przesłać dalej.
Nie wiadomo czy to proces synchroniczny czy nie itp

RequiredNickname napisał(a):

Trochę mało informacji. Gdzie ten response Id jest nadawany?
Przedstawiłeś problem tak jakbyś chciał longa zapisać w jakiejś bazie po to by go potem wyciagnąć i przesłać dalej.
Nie wiadomo czy to proces synchroniczny czy nie itp

Response id jest nadawany przez zewenetrzne api, zapisuje go aby w przypadku crash/restartu systemu zaczać konwersacje z zewnętrzym api od tego response id.

Pytanie jest proste czy istnieje jakaś przyjemna/mała biblioteka w java która pozwala mi zapisac stan do pliku i zapewnia concurency access do tego stanu.

Chronicle persisted map.

Fajne, nie znałem tego

szmeterling napisał(a):

Chronicle persisted map.

A ten persisted map robi cokolwiek żeby jakoś ochronić ten plik? Typu wsadza gdzieś backup, albo prowadzi zapis w innym miejscu, i potem robi move'a?

Bo jeśli nie, to w sumie po co tego użyć zamiast samemu zapisać plik?

Czy ja wiem w sumie po co. Własna implementacja przy tak prostym przypadku wg mnie jest bardziej zasadna. ReentrantLock albo CAS, albo jeszcze lepiej StructuredTaskScope i virtual threads. A chronicle persisted map jest off heap. Po crashu zostaje plik który w momencie ponownego zapisu go nie nadpisuje tylko otwiera. Wersja komercyjna zapewnia jakąś persystencje.

Jedno pytanie. Wg czego klient będzie otrzymywał zapisane id po crashu? Client_id z jwt? Więc mapa key=Client_id, value=response_id.

A co się stanie, jak Twoja aplikacja będzie miała wiele instancji? Czy ta apka ma w ogóle uprawnienia, żeby pisać do pliku?

W kontekście tego zapisu dopliku to się ta kzastanawiam czy autor zastanawiał się nad kwestiami np. co będzie jak będzie x plików? Czy wszystkei wtedy po kolei trzeba przeszukiwać by znaleźć potrzebny response id? Inna sprawa, że ten response id wygąda ja jakis traceId/correlationId który dziś przychodzi poprawnie a jutro może już nie przychodzić wcale i opieranie na tym logiki jest dosyć kruche.
Wątpliwości co do sensowności takiego rozwiązania mnożą się jak króliki ;)

Swietnie że pytasz, grunt to właściwa architektura:

1. Po pierwsze żeby rozwiązanie się skalowało musimy z rezygnować z transakcji. Czasy ACID się skończyły, dlatego przyjmiemy tutaj podejście eventual consistency.
2. Wykorzystajmy Kafkę jako kolejkę będziemy z instancji aplikacji wysyłać wiadomości typu (requestId, timestamp) do instancji procesorów.
3. Na tym etapie ponieważ mamy już timestamp w wiadomości możemy użyć jakiegoś frameworka MapReduce który wybierze ostatni requestId np. Hadoop
4. Na koniec żeby zapewnić sobie większoą niezawodność będziemy mieli flotę maszyn każda z jednym plikiem lastRequestId który będzie przechowywał to Id.

Także:
webServer -> Kafka -> MapReduce -> Kafka -> distributed custom storage

Najlepiej wykonać to w podejściu multicloud żeby zabezpieczyć się przed awarią inflastruktury po stronie dostawcy i uwolnić się od vendor locka.

(bpmljvśpv ebovę fbovr wnwn)

gienek64bit napisał(a):

Pytanie jest proste czy istnieje jakaś przyjemna/mała biblioteka w java która pozwala mi zapisac stan do pliku i zapewnia concurency access do tego stanu.

Nie potrzeba biblioteki
https://docs.oracle.com/en/java/javase/21/docs//api/java.prefs/java/util/prefs/Preferences.html robi to co chcesz.

The methods in this class may be invoked concurrently by multiple threads in a single JVM without the need for external synchronization, and the results will be equivalent to some serial execution. If this class is used concurrently by multiple JVMs that store their preference data in the same backing store, the data store will not be corrupted, but no other guarantees are made concerning the consistency of the preference data.

Niestety nic nie wiem o wydajności tego rozwiązania, ale strzelam, że o ile nie dostajesz tego ResponseId 100 razy na sekunde to nie ma problemu.

Preferences, albo serializuj stan do pliku .json zależy jak skomplikowane dane potrzebujesz przechowywać.