Spring менеджер транзакций и многопоточность

Я пишу многопоточную программу в serviceImpl, используя интерфейс Callable. Я использую весенний менеджер транзакций. Когда операция обновления выполняется в БД, она выполняется успешно. Но обновленные данные не отражаются в БД.Но когда я запускаю программу без многопоточности, она обновляется в БД.

Это моя конфигурация


        
            
            
            
        
    
    
        
        
    
    
        
    

Я могу перейти к другому подходу для менеджера транзакций. Просто я хочу получить подтверждение, если этот подход поддерживает или нет для многопоточности. Итак, мой вопросПоддерживает ли весенний менеджер транзакций многопоточность (я имею в виду просто объявление аннотации или XML) Почему обновленные данные не отражаются в БД в моем случае? Какой может быть лучший альтернативный подход?

Ответы на вопрос(3)

как вы делаете многопоточность, поэтому я могу только догадываться, что вы сделали:

В YourService.doSomething () он создает потоки. Для каждого потока он выполняет действия, связанные с БД. Это правильно?

Как описано в другом ответе, контекст транзакции хранится в локальном потоке. Следовательно, ваша логика в потоке не связана с какой-либо транзакцией. В этом можно убедиться, кроме логики потоков, в doSomething () вы также выполняете некоторые действия с БД. Вы обнаружите, что действия db, которые вы выполняли в doSomething (), совершаются, а действия в потоках теряются.

Один из разумных способов решения этой проблемы - обычно у нас есть уровень службы приложений, который служит единицей работы, и, следовательно, у нас есть граница транзакции (аналогично вашей службе). Ваш поток должен вызывать операции, предоставляемые сервисом. Конечно, они будут все в разных сделках.

Если вы хотите, чтобы все они были в одной транзакции, другой способ состоит в том, чтобы вместо того, чтобы отдельный поток выполнял действие БД, потоки теперь выполняют тяжелую работу и отправляют результат обратно в созданный поток (например, в очередь «производитель-потребитель»). Созданный поток отвечает за сбор результата и выполнение действий с БД.

Лично я бы постарался избежать передачи контекста транзакции вручную по другому потоку. Это просто разрушает саму идею декларативной сделки.

вы захотите реализовать свой собственный TransactionSynchronizationManager в Spring и внедрить его. Используйте что-то вроде InmheritableThreadLocal вместо ThreadLocal.

используемый Spring, хранится в локальной переменной потока. Так что если вы запускаете новый поток или выполняете код в другом потоке, используя вызываемый, этот код будетбыть частью транзакции, запущенной транзакционным аспектом Spring. Тот'почему ваши данные нене появляются в базе данных.

 JB Nizet30 мая 2013 г., 17:46
Я сомневаюсь. Как транзакционный аспект мог знать, закончил ли второй поток с транзакцией или нет? Кто завершит транзакцию в конце, если метод вернется до того, как порожденный поток (или вызываемый) завершит свою работу?
 Aaron Digulla30 мая 2013 г., 17:59
Если я'сделал бы что-то подобное, ям отвечает за правильную синхронизацию потоков. Например, может быть полезно начать работу в потоке A и завершить ее в потоке B (следовательно, передать транзакцию между потоками).
 Aaron Digulla30 мая 2013 г., 14:33
Можно ли передать активную транзакцию во второй поток?

Ваш ответ на вопрос