Почему Spring не всегда использует пакетную вставку / обновление при настройке? - PullRequest
Новая
       9

Почему Spring не всегда использует пакетную вставку / обновление при настройке?

0 голосов
/ 30 октября 2019

В моем проекте на основе Spring JpaRepository у меня есть метод, который всегда загружает записи одну за другой из метода, который вызывает saveAll (список List) ... когда я использую список, где я создаю объекты и добавляю их в список,Приведенный ниже код занимает около 5 минут ... 

@Transactional(readOnly = false)
public List<Data> saveAll(List<Data> dataList) throws Exception {
 try {
        for(Data d : dataList){

            if(d.getCol04() == null)
                d.setCol04("TEST");
            else
                d.setCol04(null);

            log.info(new Gson().toJson(d));

        }

        return dataRepository.saveAll(dataList);

    }catch (Exception e) {
        log.error("Unexpected error.", e);
        return null;
    }

}

2019-10-30 09:07:11 DEBUG org.hibernate.loader.Loader - Строка набора результатов: 0 2019-10-30 09:07:11 DEBUG org.hibernate.loader.Loader - строка результата: EntityKey [com.test.Data # component [batchSeq, batchId] {batchSeq = 866, batchId = 6012113450}] 2019-10-30 09: 07: 11 DEBUG ohengine.internal.TwoPhaseLoad - Разрешение ассоциаций для [com.test.Data # component [batchSeq, batchId] {batchSeq = 866, batchId = 6012113450}] 2019-10-30 09:07:11 Отладка ohengine. internal.TwoPhaseLoad - выполнено материализованное лицо [com.test.Data # component [batchSeq, batchId] {batchSeq = 866, batchId = 6012113450}] 2019-10-30 09:07:11 DEBUG org.hibernate.loader.Loader - выполненозагрузка объекта 2019-10-30 09:07:11 DEBUG org.hibernate.loader.Loader - загрузка объекта: [com.test.Data # component [batchSeq, batchId] {batchSeq = 867, batchId = 6012113450}] 2019-10-30 09:07:11 DEBUG org.hibernate.SQL - выберите datae0_.batch_seq как batch_seq1_0_0_, datae0_.batch_id как batch_id2_0_0_, datae0_.col01 как col3_0_0_, datae0_.col02, как col4_0_0_, datae0_.col03 как col5_0_0_, datae0_.col04 как col6_0_0_, datae0_.col05 как col7_0_0_, datae0_.col06 как col8_0_0_, datae0_.col07 как col9_0_0_, datae0_.col08 как col10_0_0_, datae0_.col09 как col11_0_0_,datae0_.col10, как col12_0_0_, datae0_.group_id как group_id13_0_0_, datae0_.parent_trans_id как parent_trans_id14_0_0_, datae0_.result_message как result_message15_0_0_, datae0_.result_status как result_status16_0_0_, datae0_.tn как tn17_0_0_, datae0_.tn_quantity_assigned, как tn_quantity_assig18_0_0_, datae0_.tn_quantity_requested, как tn_quantity_reque19_0_0_, datae0_. xml_data как xml_data20_0_0_ от owner.batch_data datae0_, где datae0_.batch_seq =? и datae0_.batch_id =? 2019-10-30 09:07:12 DEBUG org.hibernate.loader.Loader - строка набора результатов: 0 2019-10-30 09:07:12 DEBUG org.hibernate.loader.Loader - строка результата: EntityKey [com. test.Data # component [batchSeq, batchId] {batchSeq = 867, batchId = 6012113450}] 2019-10-30 09:07:12 DEBUG ohengine.internal.TwoPhaseLoad - Разрешение ассоциаций для [com.test.Data # component [batchSeq, batchId] {batchSeq = 867, batchId = 6012113450}] 2019-10-30 09:07:12 DEBUG ohengine.internal.TwoPhaseLoad - Законченная материализованная сущность [com.test.Data # component [batchSeq, batchId] {batchSeq = 867, batchId = 6012113450}] 2019-10-30 09:07:12 DEBUG org.hibernate.loader.Loader - загрузка готового объекта 2019-10-30 09:07:12 DEBUG org.hibernate.loader.Loader - загрузка объекта:[com.test.Data # component [batchSeq, batchId] {batchSeq = 868, batchId = 6012113450}] 2019-10-30 09:07:12 DEBUG org.hibernate.SQL -. ,,2019-10-30 09:10:34 DEBUG ohejbinternal.AbstractBatchImpl - Повторное использование пакетной инструкции 2019-10-30 09:10:34 DEBUG org.hibernate.SQL - обновить набор owner.batch_data col01 = ?, col02 = ?, col03 =?, col04 = ?, col05 = ?, col06 = ?, col07 = ?, col08 = ?, col09 = ?, col10 = ?, group_id = ?, parent_trans_id = ?, result_message = ?, result_status = ?, tn = ?,tn_quantity_assigned = ?, tn_quantity_requested = ?, xml_data =? где batch_seq =? и batch_id =? 2019-10-30 09:10:34 DEBUG ohejbatch.internal.BatchingBatch - Выполнение размера партии: 500 2019-10-30 09:10:36 DEBUG osorm.jpa.JpaTransactionManager - Закрытие JPA EntityManager [SessionImpl (2081270212)] после транзакции2019-10-30 09:10:36 INFO oheiStatisticalLoggingSessionEventListener - Метрики сеанса {77841799 наносекунд потрачено на получение 1 соединения JDBC;0 наносекунд потратили на освобождение 0 соединений JDBC;89273975 наносекунд потрачено на подготовку 1501 заявлений JDBC;250886005163 наносекунд потрачено на выполнение 1500 операторов JDBC;4812997147 наносекунд потрачено на выполнение 3 партий JDBC;0 наносекунд, потраченных на выполнение 0 ставок L2C;0 наносекунд потрачено на выполнение 0 попаданий L2C;0 наносекунд, потраченных на выполнение 0 промахов L2C;5462588455 наносекунд, потраченных на выполнение 1 сброса (сбрасывание в общей сложности 1500 объектов и 0 сборов);0 наносекунд затрачено на выполнение 0 частичных сбросов (сброс всего 0 сущностей и 0 коллекций)} 2019-10-30 09:10:36 DEBUG ohejinternal.JdbcCoordinatorImpl - HHH000420: Закрытие не выпущенной партии 2019-10-30 09:10: 36 DEBUG osorm.jpa.JpaTransactionManager - Создание новой транзакции с именем [org.springframework.data.jpa.repository.support.SimpleJpaRepository.findById]: PROPAGATION_REQUIRED, ISOLATION_DEFAULT, readOnly 2019-10-30 os1036. jpa.JpaTransactionManager - Открыт новый EntityManager [SessionImpl (1953492703)] для транзакции JPA. ] только для чтения 2019-10-30 09:10:36 DEBUG ohetinternal.TransactionImpl - при создании TransactionImpl, JpaCompliance # isJpaTransactionComplianceEnabled == false 2019-10-30 09:10:36 DEBUG ohetinternal.TransactionImpl - begin

SaveAll (список списка) загружается партиями, когдаЯ запрашиваю findAll (List id) и использую возвращенный список в качестве аргумента для saveAll. Ниже код занимает около 8 секунд. 

//Working method

@Transactional(readOnly = false)
public List<Data> saveAll() throws Exception {

    try {
        List<Data> dataList2 = dataRepository.findAllByBatchId(6000000L);

        for(Data d : dataList2){

            if(d.getCol04() == null)
                d.setCol04("TEST");
            else
                d.setCol04(null);

            log.info(new Gson().toJson(d));

        }

        return dataRepository.saveAll(dataList2);

    }catch (Exception e) {
        log.error("Unexpected error.", e);
        return null;
    }

}

. ,,2019-10-30 09:00:25 DEBUG ohejbatch.internal.BatchingBatch - выполнение размера пакета: 500 2019-10-30 09:00:27 DEBUG osorm.jpa.JpaTransactionManager - закрытие JPA EntityManager [SessionImpl (2038854767)] после транзакции2019-10-30 09:00:27 ИНФОРМАЦИЯ oheiStatisticalLoggingSessionEventListener - Метрики сеанса {89300419 наносекунд потрачено на получение 1 соединения JDBC;0 наносекунд потратили на освобождение 0 соединений JDBC;1037028 наносекунд потрачено на подготовку 2 заявлений JDBC;330435552 наносекунды потрачено на выполнение 1 заявления JDBC;6423148647 наносекунд потрачено на выполнение 3 пакетов JDBC;0 наносекунд, потраченных на выполнение 0 ставок L2C;0 наносекунд потрачено на выполнение 0 попаданий L2C;0 наносекунд, потраченных на выполнение 0 промахов L2C;7100764566 наносекунд, потраченных на выполнение 1 сброса (сбрасывание в общей сложности 1500 объектов и 0 сборов);2082345 наносекунд потрачено на выполнение 1 частичного сброса (сброс всего 0 сущностей и 0 коллекций)} 2019-10-30 09:00:27 DEBUG ohejinternal.JdbcCoordinatorImpl - HHH000420: Закрытие не выпущенной партии 2019-10-30 09:00: 27 DEBUG oswsmmaHttpEntityMethodProcessor - Использование 'application / json', задано [ / ] и поддерживается [application / json] 2019-10-30 09:00:27 DEBUG oswsmmaHttpEntityMethodProcessor - Запись ["{" data ":0} "] 2019-10-30 09:00:27 DEBUG osojsOpenEntityManagerInViewInterceptor - Закрытие JPA EntityManager в OpenEntityManagerInViewInterceptor

Есть идеи, почему это происходит?

1 Ответ

1 голос
/ 30 октября 2019

Может ли это быть из-за грязной функции проверки? В первом методе, когда вы сохраняете dataList перед сохранением данных, hibernate может загружать все данные в памяти, чтобы проверить, какие данные были изменены. Это может быть причиной того, почему это требует времени иЕсли Данные (сущность) дополнительно связаны с другой сущностью, то это добавляется вовремя. Если, как и во втором методе, dataList2 предварительно загружается перед сохранением в базу данных, следовательно, во время сохранения разрешение не выполняется. Чтобы проверить эту теорию, вы можете загрузить все данные (вместе со связанной сущностью) и затем сохранить, если для этого потребуется то же время, что и для второго метода, то мы можем заключить это. Пожалуйста, также обратитесь по этой ссылке https://forum.hibernate.org/viewtopic.php?f=1&t=994162&view=previous, это может помочь

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...