Kilka JVM równolegle?

Rozwiązaniem może być quartz, aby zsynchronizować crona - http://www.quartz-scheduler.org/documentation/quartz-1.8.6/configuration/ConfigJDBCJobStoreClustering.html

Dzięki poczytam o quartz.

Bardziej mi chodziło o odpowiedź na

Czy odpalenie kilka razy tego samego programu to uruchomienie kilku JVM równolegle?

Czy raczej to idzie w tej samej instancji JVM jako osobne procesy?

Zależy jak to uruchamiasz. Jak wrzucasz jary na tomcata to będzie to jedna JVM. Jak uruchamiasz jako java -jar to bedą to osobne procesy (każdy proces to inna JVM).

Jeżeli przez uruchomienie aplikacji rozumiesz odpalenie java myjar.jar i jest to cron napisany w jakimś bashu to przy każdym takim starcie wstaje pewnie nowa instancja JVMa w systemie. Mnie ciekawi czemu tego crona nie zrobisz wewnątrz aplikacji. Co do race condition: każde takie wywołanie powinno mieć IMHO swój plik zapisu np. "data_godzina_startu.txt" i dopiero "skończonych plikach" bym operował.

@marian pazdzioch:

Czy odpalenie kilka razy tego samego programu to uruchomienie kilku JVM równolegle?

Tak.

Pierwszy program startuje, po minucie dalej działa (pobiera dane z serwera). Zapisuje do pliku X.
Startuje drugi program. Zaczyna robić to samo. Piszę do tego samego pliku X.
No i jest problem bo oba piszą jednocześnie (coś jak race condition).
Jak się tego typu problemy rozwiązuje?

Jest dużo różnych sposobów, natomiast najprostszym z nich jest lockowanie przez filesystem. Tj.

1. Proces A zaczyna swoją pracę. Sprawdza, czy istnieje plik filename.txt.lock w katalogu. Nie ma go - to go tworzy. Następnie zaczyna pisać do pliku filename.txt.
2. Proces B zaczyna swoją pracę. Sprawdza, czy istnieje plik filename.txt.lock. Jest. W takim razie proces B przechodzi w tryb czuwania, tj. co jakiś czas sprawdza, czy ten plik tam jest.
3. Proces A kończy swoją pracę. Kasuje plik filename.txt.lock.
4. Proces B orientuje się w końcu, że filename.txt.lock zniknął. Tworzy go od nowa i zaczyna działać.

Oczywiście to jest bardzo prosta metoda (ale dosyć popularna). Jest wiele innych.

marian pazdzioch napisał(a):

Jak się tego typu problemy rozwiązuje?

Konteneryzacja.

@marian pazdzioch: dlaczego piszą do tego samego pliku?

@marian pazdzioch:

Twój problem nie ma nic wspólnego z wielością JVM, tylko coś masz źle oprogramowane, że się kłócą o dane (jak zauważył @yarel)
Hipotetyczne wymuszenie tego w jednej JVM (jak bym musiał, dałbym radę *), tego nie rozwiązuje.

*) Jak sobie powiem, że się będę uczył, to naprawdę będę się uczył. Tylko co ja se będę mówił Copyright by kumpel ze studiów

marian pazdzioch napisał(a):

Załóżmy że ustawiłem crona na "co minutę".

Pierwszy program startuje, po minucie dalej działa (pobiera dane z serwera). Zapisuje do pliku X.

Startuje drugi program. Zaczyna robić to samo. Piszę do tego samego pliku X.

No i jest problem bo oba piszą jednocześnie (coś jak race condition).

Jak się tego typu problemy rozwiązuje?

Jeśli chodzi tylko o system plików, to możesz założyć lock na plik, żeby tylko jeden proces do niego pisał, a drugi checkał (np open for write). Możesz też nie operować na tym pliku (nie zmieniać go), tylko zawsze tworzyć kopię, i na niej coś robić - wtedy nawet jak i 10 procesów na raz coś będzie chciało zrobić, to nie wejdą sobie w drogę. Jeśli chodzi o zapis do danych które nie są plikiem, to wykorzystuje się inne mechanizmy. Ale zawsze to jest na zasadzie, że albo jedno "coś" pracuje, a pozostałe czekają; albo nie operują na tym samym tylko na kopiach, albo to są synchronizowane operacje (jak np wątki w Javie), albo po prostu się nie zezwalana na to by więcej niż jedna rzecz na raz operowała na danych.

Na tak wysoki poziom jak blokowanie procesów w JVM bym nie wchodził.

Tak na prawdę wszystko zależy od tego co chcesz zrobić - dlaczego te programy piszą do tego samego pliku.

Można i tak: https://stackoverflow.com/a/2002948