Inicjalizacja cache w kontekście springowym

Odpowiedz Nowy wątek
2019-01-10 13:02
0

Jak zainicjowalibyście cache jako bean springowy którego wartości są pobierane z bazy danych ?
Czy takie coś jest ok ?

@Configuration
public class AppConfiguration {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Bean
    public SystemsCache SystemsCache() {
        return new SystemsCache(populateCache());
    }

    private Map<String, Integer> populateCache() {
        Map<String, Integer> cache = Maps.newHashMap();
        String selectSQL = "select key, value from table";

        jdbcTemplate.query(selectSQL,
                resultSet -> {
                    cache.put(resultSet.getString("key"), resultSet.getInt("value"));
                });

        return cache;
    }
}
edytowany 2x, ostatnio: p_maciek, 2019-01-10 16:35

Pozostało 580 znaków

2019-01-10 22:54
1

a nie mozesz po prostu uzywac jak zwyklego kesza? czyli po prostu uderzasz do kesza, nie ma tam tego co chcesz to wtedy dopiero pobierasz dane z bazy i jednoczesnie wrzuczasz do kesza?

jezeli potrzebujesz juz kesz od razu z danymi na starcie to mniej wiecej tak. mozesz tez zapiac sie na jakis event springowy np. ApplicatioReadyEvent i wtedy wrzucic dane do kesza, ale aplikacja bedzie juz gotowa, wiec bedzie mogla odpowiedziec z bazy, a nie kesza


Limitations are limitless

> ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.
edytowany 1x, ostatnio: hcubyc, 2019-01-10 22:56
No tak też bym mógł ale nie chciałem wywoływać dodatkowych zapytań w trakcie działania aplikacji, cache zawiera tylko kilka wartości. - p_maciek 2019-01-11 11:30

Pozostało 580 znaków

2019-01-10 23:36
0
hcubyc napisał(a):

a nie mozesz po prostu uzywac jak zwyklego kesza? czyli po prostu uderzasz do kesza, nie ma tam tego co chcesz to wtedy dopiero pobierasz dane z bazy i jednoczesnie wrzuczasz do kesza?

Nie no, update kesza (ponowny call do bazy) powinien być triggerowany jakąś konkretną metodą (np wywołaniem save z innego serwisu), a nie spowodowany tym, że w keszu czegoś nie ma

Przecież właśnie o to chodzi. Tego, że w keszu czegoś nie ma dowiesz się właśnie np. podczas tej próby wywołania save z innego serwisu. - Shadov 2019-01-11 12:13
Chyba się nie rozumiemy. Tego, że w keszu czegoś nie ma dowiesz się właśnie np. podczas tej próby wywołania save z innego serwisu - mówimy o zwykłym getById, nie ma żadnego save póki co. Według ciebie, jeśli getByIdnie znajdzie w cashu, to trzeba sięgnąc do bazy... a jak rozróżnisz sytuację że czegoś faktycznie nie ma, a sytuację gdzie jest w bazie, ale nie ma w cashe? Zwykłe getById powinno w takim wypadku komunikować się jedynie z cashem - oczywiście jeśli mamy pewność, że wiemy dokładnie gdzie zmieniamy bazę - np w metodzie save. - Pinek 2019-01-11 16:26
Wówczas owa metoda save powinna aktualizować cashe. - Pinek 2019-01-11 16:26

Pozostało 580 znaków

2019-01-11 17:53
0

Według ciebie, jeśli getByIdnie znajdzie w cashu, to trzeba sięgnąc do bazy... a jak rozróżnisz sytuację że czegoś faktycznie nie ma, a sytuację gdzie jest w bazie, ale nie ma w cashe?

Korzystasz z interfejsu i klient nic nie wie o tym czy pytasz się kesza czy faktycznie idzie strzał do jakiejś bazy/gdziekolwiek, a w implementacji dodajesz sobie te dwa ify.

Nie no, update kesza (ponowny call do bazy) powinien być triggerowany jakąś konkretną metodą (np wywołaniem save z innego serwisu), a nie spowodowany tym, że w keszu czegoś nie ma

W gruncie rzeczy tak moglibysmy bez końca, bo jedno i drugie znajdzie zastosowanie. Np. kesz w pamięci per instancja aplikacji i wiele instancji aplikacji i aktualizacja keszu na 'save' bedzie srednim pomysłem


Limitations are limitless

> ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.

Pozostało 580 znaków

2019-01-11 17:57
0
hcubyc napisał(a):

Według ciebie, jeśli getByIdnie znajdzie w cashu, to trzeba sięgnąc do bazy... a jak rozróżnisz sytuację że czegoś faktycznie nie ma, a sytuację gdzie jest w bazie, ale nie ma w cashe?

Korzystasz z interfejsu i klient nic nie wie o tym czy pytasz się kesza czy faktycznie idzie strzał do jakiejś bazy/gdziekolwiek, a w implementacji dodajesz sobie te dwa ify.

No nie jestem przekonany... dodając ifa, musze wykonać calla do bazy. A po to w ogóle jest kesz, żeby tego nie robić. Więc taka implementacja byłaby bez sensu

Pozostało 580 znaków

2019-01-11 18:16
0

No to zobacz: masz wiele instancji apki, kesz w pamięci. Zdecydowana większość to odczyty, nie zapisy, czyli standardowo. Kesz ma inwalidacje po jakimś czasie, ale będziesz miał aktualniejszy stan kesza gdy np. bedziesz inwalidował obiekt co minutę i przez minutę powiedzmy zaoszczędzisz 10k requestów do bazy. Z kolei na save będziesz mieć bardziej niespójny stan, bo np. ostatnie 3 zapisy odbyly się na innej instancji, a np. jakiś obiekt w ogóle nie był zapisywany od startu instancji, a przecież nie bedziesz pchał całej bazy do kesza przy starcie (powiedzmy, że w tym przypadku to nieopłacalne).


Limitations are limitless

> ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.
A, okej ;) Fakt, przy wielu instancjach to masz rację. Wtedy właśnie chyba trudno też utrzymać transakcje, i inne problemy, ale z keszem fakt :P - Pinek 2019-01-12 01:24

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0