Начиная с нуля с NHibernate: советы для нового, большого, приложения

Question

Я пишу фреймворк для переписывания существующего приложения.У нас есть модель данных около 900 таблиц с общим количеством полей 11000 и базами данных, размер которых приближается к 120 ГБ.Основными элементами моей новой реализации являются WPF, NHibernate 3, C #, .NET 4.0, NHibernate.Validator и Spring.Само приложение очень интенсивно использует данные / транзакции, и наша самая большая установка имеет около 300 одновременно работающих пользователей.

Вот несколько моментов, о которых я хотел бы услышать:хороший выбор?Почему я должен выбрать другой (Замок?).У меня проблемы со временем запуска, но я смог довести это до 14 секунд.Я не заметил особой разницы между Spring и Castle.Конечно, более короткое время запуска приветствуется;

Я использую поля Identity, но понимаю, что это не лучший вариант.Какая жизнеспособная альтернатива существует:

Отображение данных выполняется с короткими сеансами, по одному на запрос.Ввод данных, с другой стороны, имеет один сеанс / транзакцию на всю продолжительность рабочего процесса, что может занять до 10-20 минут максимум (обычно 2-4 минуты).Существуют ли альтернативы сеансу / транзакции на протяжении всего этого периода и как я могу это настроить?

Я открыт для всех и каждого материала и хотел бы объединить идеи людей, которые имеютработал дольше, и у меня больше опыта работы с NHibernate, чем у меня.

(Кстати: я знаю, что у меня над головой, но я так предпочитаю).

РЕДАКТИРОВАТЬ: Я был слишком резок в отношении HiLo, но после некоторого исследования Guid, кажется, лучше подходят моей ситуации.

Answer 1

Hilo - самый быстрый подход к назначению идентификаторов. Использование полей идентификаторов работает и безопаснее (см. Ниже), но поскольку идентификатор генерируется базой данных, каждая вставка строки требует операции чтения для определения идентификатора строки.

Если вы собираетесь использовать hilo, убедитесь, что вы понимаете детали того, как работает алгоритм. (Я думаю, что это описано в другом месте на этом сайте.) Если вы сделаете неправильный выбор для типа данных столбца или hilo, или для значения "lo", вы можете в итоге получить обтекание, которое приведет к генерированию уже используемых чисел, что, конечно, очень плохо.

Типичный способ обработки ввода данных - закрыть сеанс, выполнить ввод данных, а затем прикрепить обновленные объекты к новому сеансу. Это описано в документации.

Хитрость с присоединением заключается в следующем: скажем, что объект A содержит ссылку на объект B, а объект B содержит ссылку на объект C. Если вы «прикоснулись» к объектам A и B во время начального сеанса, A и B будут были загружены, и B будет содержать ссылку на прокси-сервер C. Если вы присоедините A к новому сеансу, но забудете присоединить B, ссылка на прокси-сервер B все равно будет указывать на старый закрытый сеанс, что приведет к исключению, если вы попытаетесь следовать этому.

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

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

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