Необходима параллельная синхронизация на переходных полях сущности JPA?

Мы знаем, что два потока, управляющих одним и тем же объектом одновременно, будут вызывать OptimisticLockException, если применяются все значения по умолчанию. Что произойдет, если поле (области), которое обрабатывают потоки, было отмечено аннотацией @Transient или модификатором transient?Необходима параллельная синхронизация на переходных полях сущности JPA?

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

Однако у меня есть все мои книги Java EE и спецификация JPA 2.0, но я не могу найти эту проблему. Это говорит мне, что мне что-то не хватает, и что я слишком беспокоюсь ??

источник

2013-05-03 Martin Andersson

OptimisticLockException будет использоваться только в том случае, если в объекте есть поле @Version, и если транзакция пытается сохранить объект, который был изменен другой транзакцией, поскольку состояние объекта было загружено.

Каждая транзакция имеет свой экземпляр каждого объекта, который он загружает. Объекты не являются потокобезопасными и не должны использоваться несколькими потоками.

Переходные поля действительно игнорируются JPA. Но я не вижу, как синхронизация может что-то изменить, поскольку каждый поток имеет свой собственный экземпляр объекта. Более того, в большинстве корпоративных приложений несколько JVM используют одну и ту же базу данных, поэтому синхронизация там не помогает. Честно говоря, использование переходных полей в объектах обычно демонстрирует проблему проектирования, и полагаться на состояние переходного поля в объекте для хранения состояния, разделяемого несколькими потоками, совершенно неверно. Если состояние разделяется несколькими потоками или даже процессами, оно, вероятно, должно быть сохранено в базе данных.

источник

2013-05-03 19:18:18

Рассмотрим случай, когда у нас есть '@ Singleton', также отмеченный' @ConcurrencyManagement (ConcurrencyManagementType.BEAN) '. Удаленные клиенты, сервлеты и другие EJB: все они используют этот синглтон .. много. Singleton управляет коллекцией [отдельных] сущностей. Каждый объект имеет временную ссылку на другой объект. Отношения являются лишь частью текущего состояния приложения. Таким образом, не разделяет ли потоки ссылки на отдельные ссылки? Если бы это было семантически правильно, скажите, что сущность - это Человек, беседующий с другим Человеком прямо сейчас, вы все еще считаете, что это плохой дизайн? –

Отделяемое сущность - не что иное, как простой старый объект Java. К ним применяются те же правила параллелизма, что и для любого другого объекта. Таким образом, это не имеет никакого отношения к JPA, и является ли атрибут временным или нет, не имеет значения. Если у вас такой дизайн, читайте о параллелизме и безопасности потоков в целом. Не ищите ответа в JPA, потому что JPA не имеет значения в этом сценарии. –

Спасибо, JB Nizet, оцените его. Однако я не могу согласиться с тем, что отдельная сущность ** не более **, чем POJO. См. Спецификацию JPA 2.0, стр. 79: «Отдельные экземпляры сущностей [..] больше не гарантируются для синхронизации с состоянием базы данных». Слово было «гарантировано». Книга «Pro JPA 2» написана на с. 160: «Некоторые поставщики могут попытаться разрешить взаимосвязь» отдельного объекта, если мы обратимся к его ленивому атрибуту загрузки. И JavaDocs EntityManager # merge принимает «экземпляр объекта». В сущности, вы правы. Думал, я просто указываю пару нюансов для третьей стороны. –

Необходима параллельная синхронизация на переходных полях сущности JPA?

ответ

Смежные вопросы