Petro123slipperyпропущено...


Классическая длинная транзакция не вариант как мне кажется, потому, что параллельно в веб приложении таких транзакций может быть открыто 1000 и более и открыты они могут быть на часы, насколько я понимаю это неимоверная нагрузка на СУБД так же и на память самого сервера. Если я ошибаюсь и у кого-то есть какие-нибудь сведения или информация по этому поводу с огромным удовольствием выслушаю. Но я всегда слышал, и где-то читал, что делать так в веб приложении в котором могут параллельно работать тысячи или десятки тысяч пользователей, это значит "убить" проект. Хотелось бы мне ошибаться.....
говорят, за мкадом нет жизни и в Сибири медведи на улицах.
Это из той серии.
Серьёзные проекты начинают с ТЗ.
Твой заказчик захотел супер Универсальности. Но ТЗ грамотное не составил.
Если зайти на форум Проектирование ИС - они бы до кода даже не дошли.
Потому что нет ТЗ.
Сколько у тебя пользователей?

ну к сожалению ТЗ ставится как ставится, я наемный работник, а не отдельная фирма взявшая заказ, мне пришел главный дядя и сказал хочу чтоб было так и так, и не просто сказал, а вообщем-то подробно объяснил задачу, примерно также как я её рассказал тут на форуме, скопирую описание задачи еще раз в этот форум:

реализовать универсальный визард(карточку) для работы со всеми объектами системы. Для каждого объекта будут разные наборы закладок и определяться в зависимости от того какие интерфейсы реализует объект, для разных объектов могут использоваться одинаковые закладки, ну к примеру если объекты входят в систему безопасности, то для таких объектов будет вкладка «доступ». Переключения между вкладками может быть в произвольном порядке, а не в строгом, как у настоящего визарда.

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

Данные созданные на закладке с номером 1 должны быть видны(доступны) на закладке 2, причем закладка 2 разрабатывается с незнанием о закладки 1, поэтому данные должны выниматься для разработчика прозрачно к примеру через hql запрос, дополнительные варианты рассматриваются. То есть если на закладки 1 добавили пользователя, а на 2 закладки нужно работать с существующими пользователями, то пользователь добавленный на закладке 1 должен присутствовать в выборке полученной на второй закладке. Выборки на второй закладки будут с условиями, поэтому пользователи добавленные на закладки один попадают в выборку на закладке 2, если соотвествуют указанным условиям выборки.
Данные добавляемые на всех закладках не доступны другими пользователям или другим визардам, то есть если мы добавили какого-то пользователя, но не провели заключительного "комита" то этот пользователь не должен попадать в выборки в системе, кроме выборок того же визарда в котором пользователь добавлен

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