Замок ActiveRecord возвращает идентификаторы из неправильной таблицы на CreateAndFlush - PullRequest
0 голосов
/ 27 января 2012

Я использую Castle ActiveRecord в складском проекте. У меня есть несколько таблиц, которые часто обновляются: подача, стек, stack_location. Если происходит много (добавляется подача, формируются стеки), иногда идентификатор, который устанавливается для объекта после вызова CreateAndFlush, является идентификатором из другой таблицы. База данных - MySQL, столбцы ID - это int (11), а не первичный ключ auto_increment. Я использую PrimaryKeyType.Native для свойства ID.

Я также страдал от следующей проблемы: Как получить последний идентификатор вставки в Castle ActiveRecord? но только с моей таблицей подачи (и у меня обычно есть что-то вроде 4 стеков / подача). Я добавил ловушку в эту ситуацию со сном в 5000 мс и впоследствии с SaveAndFlush, что гарантирует, что я получу идентификатор в этот момент.

Мне нужно вызвать flush напрямую, потому что мне нужен идентификатор, чтобы записать его в ПЛК, который передаст его мне позже. Мое приложение является многопоточным, но если я прав, есть только один поток, пишущий в базу данных, когда все идет не так. У меня нет ничего помеченного как изменчивое, нет никаких блокировок, препятствующих доступу к базе данных из нескольких потоков, но я предполагаю, что Castle ActiveRecord выполняет блокировку там, где это необходимо.

1 Ответ

0 голосов
/ 02 февраля 2012

Как уже упоминалось в комментарии к моему вопросу:

Я ненавижу отвечать на свои вопросы, но, похоже, я обнаружил, что все делаю неправильно. По-видимому, nHibernate намеренно не поддерживает потоки. Из-за этого мне нужно позаботиться о сессиях nHibernate, которые используются внутри разных потоков. В Castle ActiveRecord решение, по-видимому, заключается в использовании блоков «using (new SessionScope ())» в потоках для решения этой проблемы. Если у кого-то есть лучшее предложение или более четкое объяснение, я, очевидно, заинтересован.

Все проблемы, которые у меня были, больше не возвращались.

...