Контроль, когда SQL UPDATE выполняется на классах ehcache

Question

Мы используем Hibernate и ehcache в качестве кэша 2-го уровня.

Если я загружаю кешируемую сущность (например, cache-using = "read-write") и обновляю ее, кажется, что это немедленно приводит кв SQL UPDATE.

(Как) Могу ли я влиять, когда происходит SQL UPDATE?

        hibSession = HibernateUtil.getReadWriteSession();
        tx = hibSession.beginTransaction();
        User u = (User) hibSession.load(User.class, user_id);
        u.modify();
        hibSession.update(u);
        tx.commit();

Редактировать: Кажется, что установка CacheMode должен иметь эффект, но каждый hibSession.update () приводит к немедленному обновлению SQL, независимо от того, какой CacheMode я установил.

Answer 1

Если я загружаю кешированную сущность (например, cache-using = "read-write") и обновляю ее, создается впечатление, что это немедленно приводит к SQL UPDATE.

Это, кажется, очень хорошая вещь для меня.

Кажется, что установка CacheMode должна иметь эффект, но каждый hibSession.update () приводит к немедленному обновлению SQL независимо от того, какой CacheMode я установил.

ОБНОВЛЕНИЯ SQL выполняются, когда сеанс сбрасывается (когда здесь передается tx), и это только ожидаемое поведение. В «1015» я не вижу ничего, что могло бы изменить это, и я действительно не понимаю, почему вы хотели бы изменить это поведение. Я имею в виду, когда вы хотите, чтобы ОБНОВЛЕНИЯ были выполнены? Вне сделки? Я должен что-то упустить. Вы можете уточнить?

---

Обновление: Похоже, вопрос был о кэшировании с обратной записью. Итак, цитируя Hibernate Интеграция Терракоты , чтобы уточнить:

Запись за кэшированием

Когда вы думаете о кеше, вы получите эти стратегии кэширования: Read-Through Кеширование, сквозное кеширование, Писать за кэшированием. Спящий второй Уровень кеша - Read-Write-Through Кэш , где в случае отсутствия кэша, сущность читается из базы данных, а затем передан в кеш для последующего доступ. Но H2LC не является записью позади кэширование . С терракотовым диском постоянство и асинхронный модуль это было бы действительно эффективно для определенные варианты использования для реализации отложенная запись. В данный момент Hibernate просто напрямую пишет в базу данных . Вместо если его изменить, чтобы написать второй уровень кеша и постоянный async-database-queue, это будет уменьшить задержку и увеличить пропускная способность резко.

Write-Behind - это совсем не то, как работает Hibernate.