Inicjalizacja cache w kontekście springowym

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;
    }
}
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

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

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

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

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).

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