DataContext и List через native SQL

Всем доброго дня!
У меня есть большой список продуктов, порядка 40 тыс. единиц, принял решение загружать его через jdbcTemplate, и маппить на сущность Product
У меня есть Screen, в productDl которого я гружу этот список

    private Collection<Product> productsDlLoadDelegate(LoadContext<Product> loadContext) {
        return productService.loadOnlyProducts();
    }

В дальнейшем я выбираю необходимые мне продукты, и хочу сохранить содержащую их сущность через стандартные действия StandartEditor, в частности commitChanges().
Приложение зависает на этом вызове
EntitySet committedEntities = getScreenData().getDataContext().commit();
Я обнаружил, что DataContext считает List моих продуктов (все 40к записей) как modifiedInstances
image
Соответственно, как я понимаю, пытается их сохранить при вызове commitChanges() , что, как я предполагаю, вызывает зависание приложения.
Подскажите, пожалуйста, как эту проблему можно обойти? Спасибо

Евгений, добрый день!

В данном случае есть несколько вариантов:

  • Грузить сущности обычным образом, чтобы они не считались новыми. Я ведь правильно понимаю, что это обычные персистентные сущности, которые просто в этом экране загружаются нестандартным образом? 40к записей не выглядит как какое-то критичное число и обычно без проблем загружаются и обрабатываются нашими экранами с использованием paging-a в таблицах, gird-ах и специальных компонентах, таких как EnititySuggestionField.
  • Если по каким-то причинам совсем никак нельзя грузить сущности через ORM, лучше сделать их неперсистентными и везде обрабатывать только через свой сервис. Однако, опять же, 40к записей - это далеко не то количество, ради которого требуются такие ухищрения.

Я бы посоветовал не обходить проблему сохранения, а взглянуть на проблему заставившую использовать jdbc вместо ORM. Может EnititySuggestionField решит ее?
Если нет, опишите, пожалуйста, из-за чего пришлось принять такое решение? К медленной загрузке могут, например, приводить ошибки в описании reference-полей сущностей или неправильное использование fetch plan-ов.

С уважением,
Дмитрий