Операции записи не разрешены в режиме только для чтения (FlushMode. MANUAL ).ВРУЧНУЮ):

#grails #service #transactions #spring-transactions

#grails #Обслуживание #транзакции #spring-транзакции

Вопрос:

Grails 1.3.7

У нас есть метод обслуживания, который объединяет 2 пользователей. Из-за большого объема данных для этого требуется довольно много чтения, обновления и записи. У нас в сервисе transactional=true . Я понимаю, что режим сброса по умолчанию для Grails — AUTO . И я понимаю, что означает это сообщение об ошибке.

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

Я знаю, что могу изменить поведение FlushMode по умолчанию, но я сомневаюсь, поскольку я не могу дублировать поведение в любой среде, кроме рабочей. Прямо сейчас мне просто интересно, есть ли что-нибудь, что могло бы вызвать это, что на самом деле не было бы связано с FlushMode?

Дословное сообщение об ошибке:

org.springframework.dao.InvalidDataAccessApiUsageException: операции записи не разрешены в режиме только для чтения (FlushMode. MANUAL.ВРУЧНУЮ): переведите сеанс в режим FlushMode.ЗАФИКСИРУЙТЕ / АВТОМАТИЧЕСКИ или удалите маркер «Только для чтения» из определения транзакции.

Комментарии:

1. можете ли вы показать какой-нибудь код и / или сообщение об ошибке?

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

3. Gregg — у вас есть кэш второго уровня, настроенный на использование: только для чтения? По какой-то причине я думаю, что видел что-то подобное, когда я пытался изменить объект домена, для которого у меня был настроен кэш только для чтения.

Ответ №1:

Я также вижу ошибки, подобные этим, в моем приложении Grails 1.3.7. В моем случае в моей серверной базе данных возникли некоторые проблемы с конфликтом блокировок, из-за которых приложение выдает исключение CannotAcquireLockException. После нажатия одного из них мы увидим множество точно таких же исключений invaliddataaccessapiusageexception, которые вы видите (по совпадению, это также произошло только в нашей среде prod, а не в dev или test)

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