Будет ли Hibernate использовать настроенный EhCache 2-го уровня с этим поиском для нескольких идентификаторов

Я использую Hibernate 4.3.11.

Я настроил кеш 2-го уровня для своего класса Song, но не получил много обращений, и мне интересно, потому что я обычно получаю свой класс Song следующим образом.

 public static List<Song> getSongsFromDatabase(Session session, List<Integer> ids)
        {
            try
            {
                List<Song> songs = session
                        .createCriteria(Song.class)
                        .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
                        .add(Restrictions.in("recNo", ids)).list();
                return songs;
            }
            catch (Exception e)
            {
                throw new RuntimeException(e);
            }
        }

Это просто получение по первичному ключу, но нужно ли мне использовать Ehcache по-другому?

Я думаю, что это работает только тогда, когда я использую метод поиска одного Id

public static Song getSongFromDatabase(Session session, Integer id)
    {
        try
        {
            return (Song) session.get(Song.class, id);
        }
        catch (Exception e)
        {
            throw new RuntimeException(e);
        }
    }

hibernate ehcache hibernate-4.x
person Paul Taylor    schedule 17.10.2018    source источник
comment
Он не извлекается по первичному ключу. Он выполняет запрос. Вам нужен кеш запросов для кэширования результатов этого запроса. Примечание: ваши блоки catch действительно бесполезны. Они только скрывают исходное исключение времени выполнения.   -  person JB Nizet    schedule 23.10.2018
comment
@JBNizet, но recNo является первичным ключом, так что я просто получаю его неправильным способом, то есть могу ли я получить несколько записей по первичному ключу, не считая это запросом или нет?   -  person Paul Taylor    schedule 27.10.2018
comment
@JBNizet кажется, я не могу делать то, что хочу, до Hibernate 5 - мысли-на-java.org/fetch-multiple-entities-id-hibernate   -  person Paul Taylor    schedule 29.10.2018

Ответы (1)


arrow_upward
1
arrow_downward

Все зависит от того, как у вас настроен кеш 2-го уровня.

Если объект аннотирован @Cache, он действительно будет кэширован во время session.get.

Для запроса вам нужно сделать его кэшируемым. Что означает в вашем случае сделать что-то вроде этого:

List<Song> songs = session
  .createCriteria(Song.class)
  .setCacheable(true) // here
  .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
  .add(Restrictions.in("recNo", ids)).list();
person Henri    schedule 31.10.2018
comment
Я надеялся избежать добавления queryCache при простом поиске по идентификатору, но да, я понимаю, что это работает. Будет ли добавлен только один элемент в кеш запросов для этого запроса, или он добавляет один элемент для каждого другого набора значений для переменной ids. Сохраняет ли кеш запросов только идентификаторы, т.е. его использование памяти минимально по сравнению со стандартным кешем, или он действительно хранит объекты, которые нужно получить? - person Paul Taylor; 01.11.2018
comment
Я не уверен. Я думаю, что если объекты также кэшируются, запрос будет кэшировать список идентификаторов, а затем разрешать их в кеше объектов. Но, пожалуйста, проверьте это. Кстати, почему вы делаете разные, так как выбор осуществляется по идентификаторам? Все равно будет отчетливо. - person Henri; 03.11.2018
comment
Хороший вопрос, я не знаю, почему я это делаю (я думаю, я просто пытался убедиться)! - person Paul Taylor; 03.11.2018