Здравствуйте, такая ситуация:
Хочу отдельно сущности (POJO) с бизнес логикой, отдельно персист на основе Hibernate. Так чтобы логика могла обращаться к персисту по вопросам CRUD. С простыми операциями все решается, но у меня возникают ситуации, когда перед сохранением сущности нужно выполнить ряд действий с целью вычисления некоторых из ее свойств и проверки на возможность сохранения. При этом в процессе выполнения действий могут быть получены из базы/созданы другие сущности и они так же должны быть сохранены (в случае успешной проверки). Вопрос: куда мне приткнуть эти проверки и действия? сделать их методами самой сущности? не могу потому что проверка+создание других сущностей+запись должны выполняться в одной транзакции, а прямой доступ к сессиям и транзакциям из логики делать я не могу. Вынести отдельно - ну все-таки это личное дело сущности, как проверять и что делать перед записью, получается некрасиво.

Petro123, Blazkowicz , большое спасибо за ликбез и ссылки. Теперь, если можно, давайте на примере. Я придумал пример приложения, которое описывает мою проблему.
Есть благотворительное общество "ЖОР", производящее и бесплатно предоставляющее конфеты "Драже красное" и "Драже зеленое" (всего два вида) для детей из неблагополучных семей в любых количествах. "ЖОР" предоставляет конфеты в ящиках. В каждом ящике два отсека, по одному для каждого вида драже. Емкость отсеков, их соотношение и размер ящиков могут быть изменены произвольно по желанию "ЖОР". И есть группа добрых людей "Детолюбы" , в свободное от работы время упаковывающие конфеты в мешки, и непосредственно раздающие детям. Единственное требование "ЖОР" - чтобы на мешках с конфетами были напечатаны номера ящиков, из которых взяты конфеты. Каждый мешок может содержать конфеты только одного вида. Процедура упаковки такая: "Детолюб" смотрит, есть ли у него в ящиках конфеты нужного вида. Если есть, насыпает в мешок сколько нужно и ставит печать с номером ящика, если не хватает, берет следующий ящик и сыпет из него. Если у него закончились ящики, идет в "ЖОР" и берет новый, и так пока не заполнит мешок конфетами. Мешки, кстати, тоже разного размера все. Таким образом, после упаковки мы имеем мешок с конфетами, на котором один или несколько штампов с номерами ящиков. Может случиться так, что "ЖОР" откажется предоставить очередной ящик с конфетами, таким образом не будет достаточно конфет чтобы заполнить мешок. Тогда "Детолюб" должен высыпать из мешочка то что он туда уже насыпал обратно в те ящики, из которых брал. "Детолюб" никогда не может взять ящик "про запас". Только для того чтобы положить оттуда в мешок что-нить. Если вдруг ребенок вернет мешок с конфетами, "детолюб" обязан высыпать все в ящики из которых брал, и если один из ящиков окажется полным, немедленно вернуть его в "ЖОР", и попросить следующий только когда он реально понадобится.

Вот такая у меня история. Помогите мне, пожалуйста, найти хорошее отражение такой предметной области. Приложение должно автоматизировать деятельность "Детолюба", то есть предоставлять детям мешки с конфетами, и реализовывать описанные алгоритмы его поведения. Нужно использовать хибернейт. Небольшую иллюстрацию прилагаю.

Petro123,
ОК, пишем классы. Чтобы сильно много не писать, немного упрощу и изменю задачу. Ребенок сам приходит к "Детолюбу" и просит его дать ему мешок с конфетами, детолюб записывает пожелание ребенка, и пытается его выполнить - то есть найти конфеты в требуемом количестве. С учетом хибернейта, нарисую сначала статику:


Теперь нужно разобраться, где будет производиться заполнение partList и где будет проверяться, возможно ли выдать нужное количество конфет. Пусть новые Box-ы от "ЖОР" выдает специальный сервис:


Этот сервис заботится о том, чтобы выдать коробку с "ЖОР", иногда может отказать в выдаче и выбросить исключение
Также пусть будет сервис, который выдает список коробок, уже полученных от "ЖОР", из которых уже когда-либо выдавались конфеты:


Теперь можно написать алгоритм обработки, или, насколько я понял, бизнес - транзакции.Пишу прямо здесь, так что может быть море ошибок.


Вот, теперь вопрос, как будет выглядеть та часть программы, которая будет отвечать за сохранение результатов этой транзакции в базу и откат в случае эксепшна? Ведь это чистая логика, я не хочу прямо сюда писать хиберню, но хочу чтобы у меня однозначно выполнилась такая транзакция: в случае успеха(когда конфет хватает) чтобы сохранился сам SweetPack, все новые Box(это самостоятельные сущности), и список частей SweetPack-а. В случае провала - чтобы сохранился только SweetPack, список частей очистился, все новые Box-ы не попали в базу. Кроме того, мне нужна такая штука: если ни у одного SweetPack нет ссылок через их списки на Box, я хочу чтобы этот Box был удален из базы. Уменьшение количества ссылок может происходить при реализации поведения "аля 1С" - когда я сознательно чищу список SweetPack, но не удаляю его самого.

ну и вид конфет пусть один будет, забыл написать

Petro123, меняю постановку. Пусть у меня будет n видов конфет. Тогда классы изменятся следующим образом:

Блин..случайно энтер нажал. Продолжим. process() тоже изменится, но весь его описывать уже не буду. Вообщем получается так, что process() это и есть мой детолюб. Он получает заявку от ребенка - объект SweetPack, и инструкции что делать с этим объектом. А делать он может следующее:
1. Просто запомнить, что ребенок хочет конфет=записать объект с пустым списком partList.
2. Исполнить заявку - то есть записать объект, заполнив его partList - если не получит отлуп от JORService.
3. Принять от ребенка мешок обратно - очистить partList, записать объект.+ проверить, остались ли ссылки на используемые боксы. Если нет - удалить их.
Исходя из этого, можно сказать, что Petro123 Кроме того. "Пошел за ящиком" это тоже подлежит автоматизации)))? подлежит! потому как именно process()-детолюб ходит за ящиком JORService.getBox(). Также из этого следует, что пользователь системы - это ребенок.Он составляет заявку - заполняет каких конфет и сколько он хочет в SweetPack, он определяет что с этим делать, нажимая на кнопки сохранить, выполнить и отмена (пункты 1,2,3) выше.
Вообщем придется добавить в код вот это:


Теперь пункты 1,2,3 подробнее с точки зрения состояний объектов:
1. Сохранение - может применяться как к вновь созданному объекту, так и к полученному от персиста из базы. В первом случае объект просто записывается с пустым списком- process(SAVE) . Во втором - если список пуст, то просто записывается, если же список не пуст, то есть заявка выполнена, придется запускать process(POST) -потом записывать , так как данные могли измениться.
2. Выполнить - тоже как для вновь созданного, так и полученного объекта. при этом вне зависимости от состояния списка выполняется process(POST), потом записывается объект
3. Отмена - только для объекта полученного из персиста, у которого список не пуст. очищается список, объект записывается process(CANCEL)
То есть во всех трех случаях вне зависимости от проверок объект записывается, все варианты относятся только к состоянию списка - то есть заявку от ребенка детолюб примет в любом случае, вопрос сможет ли он ее выполнить, и захочет ли этого сам ребенок. Поэтому эта фраза Petro123Неудача или откат - это вернуть все как было до начала транзакции. Не совсем верна, объект полюбому надо записать, а вот список надо очистить в случае неудачи. Как-то так.
Возвращаясь к баранам 1.С какой стороны прикрутить персист сюда, не мешая его с логикой? 2. Как обеспечить удаление боксов на которые нет ссылок?

Petro123, мы очевидно друг друга не понимаем, по крайней мере я вас не понимаю. Я почти уверен, что плохо объясняю чего хочу. Может быть вариант использования поможет, пытаюсь объяснить его максимально подробно. Я именно его и подразумевал когда писал классы. Все что за рамками этого варианта, оставим.
ВИ1: Новая заявка.

1.Пользователь открывает форму заявки на конфеты.
2.Пользователь вводит желаемое количество конфет и их вид.
3. На форме три кнопки: сохранить, выполнить, отменить. Так как заявка новая, кнопка "отменить" неактивна. Пользователь хочет, чтобы его заявка была выполнена немедленно - и он нажимает на кнопку выполнить, немедленно запуская тем самым процесс выполнения заявки (многострадальный метод process()). Пока выполняется этот метод (выполняется он быстро, менее 5 секунд), пользователь ждет и не имеет возможности жмякать на кнопки.
4-1. Если заявку удалось выполнить, пользователь получает сообщение "заявка выполнена", кнопка "отмена" становится активной, на вкладке формы "информация о заявке" появляются данные об источниках конфет для выполнения заявки. Кроме того, пользователь, занимающийся отчетностью, сможет увидеть выполненную заявку в своих отчетах.
4-2. Если заявку не удалось выполнить, пользователь получает сообщение "заявка не выполнена" с указанием причин отказа, состояние активности управляющих кнопок не меняется, введенные данные сохраняются (то есть пользователь может закрыть форму, съездить в Крым, потом найти уже заполненную форму в списке, открыть и попытаться нажать кнопку "выполнить" снова), вкладка "информация о заявке" содержит пустой список.

Вот еще уточняющие моменты:
Petro123Итак, нафига тебе:
- сохранять состояние процесса между сессиями, помня, что это Веб - запрос 40 миллисекунд = ответ, забыл о нём?
- ты точно хочешь пойти по пути а-ля MTS - "Ваша заявка принята - результаты в Меню-СостояниеОперации"?
-про веб я ни слова нигде не говорил
-про сохранение информации между сессиями тоже (ну если считать сохранение сущности - то говорил, но это обычный персист. Да и что тут сверхъестественного? сохранил я заявку, через месяц открыл посмотрел, как тему в форуме например. Сохранение делал один вызов process() - одна транзакция, второй раз открою - обработкой будет заниматься другой process() -другая транзакция, между ними никакой связи нет)
-я просто хочу знать, как мне описать метод process() системы, выполняющий заявку, чтобы непосредственно в нем не использовать напрямую методы хибернейта.

Пересмотрите предыдущие посты с этой точки зрения, и тогда, я думаю, мы будем смотреть на ситуацию с одного бока. Так что process() - это все-таки детолюб , основная часть системы, обрабатывающая заявку пользователя. Сам по себе, как и живой детолюб, он не имеет состояний. Он переводит из одного состояния в другое саму заявку. То есть process() - это ровно то, чем я заменил живого детолюба. При этом модель получается анемичной в том смысле, что сущность "Заявка на конфеты" не обладает инкапсулированным поведением, за поведение отвечает метод сервиса, которому такая сущность передается входным аргументом. Повторюсь не помню какой раз - моя проблема в том что я не знаю как подружить process() и Hibernate, обеспечив целостность транзакции и не вызывая напрямую методов Hibernate, потому что в process() - моя логика, и я не хочу мешать ее с персистом.

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

Petro123, опять непонятки. Мне надо идти на курсы ясного выражения мыслей наверное. Давайте другую абстракцию попробуем, чтобы слово заявка вас так не смущало.
Вам нужны продукты, у вас есть ребенок. вы можете:
а) написать ему записку "чокупить" и сразу отправить в магазин
б) написать ему записку в понедельник, а отправить с этой запиской в магазин в пятницу.

Petro123==== Нельзя. 1. Отменять нечего. Нельзя навешивать на одно окно (контроллёр) кучу логики с Enable-Disable\Visible
2. Либо кнопка Сохранить, Либо Выполнить - это к Вашим спецам по Визабилити. Они подтвердят.
Что плохого когда на форме есть и сохранить и выполнить и отменить? по-моему это удобно. Это как раз отражает в одном месте все то, что можно сделать с заявкой. Как это будет с отдельно сохранить/выполнить нарисуйте, если не сложно. я плохо себе такое удобство представляю.

Petro123 Зачем вы удлинняете процесс, который можно решить за 0,1 сек?
Да ничего я не удлиняю, просто прикинул сколько он будет выполняться на абсолютном корче при хреновом канале связи. В нормальных условиях пользователь и не заметит времени выполнения.

Petro123А - без заявок, в он-лайне - сразу результат, либо конфеты, либо Отлуп )))
Именно так, но с небольшим уточнением. Приходите вы в ресторан, смотрите меню, и говорите: мне борщ, котлеты, пельмени, графин водки, торт, суши, пиццу и орешки. Официант говорит - ничего нет, приходите завтра(отлуп). И вы приходите, опять листаете меню и начинаете вспоминать, что же вы там заказывали(херово). А надо так: отлуп получили, заказ не получили, но информация о нем осталась, и вспоминать мучительно потом не придется.

Petro123Б - с заявкой. Но тогда нужны механизмы блокирования рессурса для заявки. Разумеется нужны, но только на время выполнения process(),а это быстрый метод. Это во-первых, во-вторых блокировка ресурсов пока за рамками обсуждаемой задачи.

Petro123Пока нет ТЗ на вариант Б, сложно искать техническое решение.
Сначала классы, потом ВИ, теперь ТЗ)). почему сложно искать техническое решение именно для того вопроса который я задаю в каждом посте?

Petro123Я вас понял, но почему нужна именно заявка, а не сразу - результат за 0,1 сек?
ААААА!!!!! -мне результат нужен, мне безуууумно нужен результаааат. НО, если получить его я не могу, я хочу чтобы исходные данные остались в форме и все. Чтобы я мог открыть ее потом, и попробовать получить результат снова, не вводя никаких больше данных

Petro123======== кто сказал что он ждёт? Если вы специально делаете ограничение (неасинхронный процесс), то это одно.
Я вам говорю - он ждет, один поток, никакой асинхронности и точка.(в рамках моего вопроса)


Petro123Аналог жд. билеты. Что оооочень хреново. В одной кассе балеты на вагон есть, в другой - нет.
Согласен, такой проблемы избежать практически невозможно ,с той точки зрения что когда кассир смотрит наличие блиетов - может видеть устаревшую информацию на какой-нить необновленной страничке, но попытка продать/забронировать уже проданное место все вернет на круги своя. так что это мы отнесем к разряду вынужденных неудобств,и (в рамках моего вопроса) это меня абсолютно не беспокоит.

Petro123- ваш Процесс претендует на длинную, либо через состояние, либо через механизмы самого хибера
Это не штатный режим. Да где это он на длинную претендует? С чего вы взяли? Нет у Процесса никаких состояний, нету. Состояние есть у заявки плохое слово, обзовем ее документом, как в 1с, вы ее упоминали, значит знаете как она устроена. Документ в 1с может быть просто сохранен, может быть проведен - у него есть состояния, а у процесса ничего нет - это просто алгоритм "проведения".

Petro123,
Petro1234-1. Если заявку удалось выполнить (АвиаБилет куплен), пользователь получает сообщение "заявка выполнена(АвиаБилет куплен)", кнопка "отмена" становится активной (??? Вернуть Билеты?)
Вот, теперь я понял где я вас запутал, и запутал конкретно. Прощу прощения, пользователь, используя ваши аналогии - это кассир, а не пассажир. И он вполне может отменить продажу билета, если, например, ввел некорректные данные. Впоследствии, он их исправит и выполнит еще раз. Разумеется, не во всех случаях можно редактировать уже выполненные/проведенные/активные (как удобнее) документы/заявки. Но это тоже оффтоп

Petro123,
Petro123Итак, чем кассир отличается от пользователя?

Полномочиями, я не делаю продажу жд билетов или вообще билетов, почему вы в пример приводите мне то, чего у меня и близко нет? Отдельные аспекты возможно, но нельзя же так обобщать. Я пытаюсь придвинуть то что я написал поближе к вашим постам просто чтобы говорить об одних и тех же вещах. Какие 400 рублей?
Если так удобнее, пусть голос внутри головы говорит кассиру что вводить, и нет никаких других пользователей, и вселенский разум наделил его полномочиями отменять выполненные заявки. Я не хочу выяснять почему он может или не может это делать, правильно ли это с точки зрения железной дороги и воздушных сообщений.
Аксиома: мой пользователь МОЖЕТ нажимать на кнопки которые у него есть: сохранить, отменить, выполнить. Исходим из этого.

Petro123,
я перестаю вас понимать совершенно. Ничего я ниоткуда не вырываю. Зачем нужен пример из жизни? я привел четкий, пусть и нереальный пример, написал что я хочу получить, как я хочу это получить. Я сознательно не лезу ни во что другое (журналы проводок, блокировку ресурсов, юзабилити) только потому, что меня интересует отдельный конкретный вопрос, и ничего больше. Я вижу от вас все что угодно кроме ответа на него, не считая этого:
Petro123ЗЫ. В 1С над документом есть процесс - Журнал документов. Где проводки выстраиваются по очереди.
Так что не надо вырывать разговор о мелком из большого.
Если вырывать, то нет проблем - Вам сказали - выкинуть хибер и на ODBC делай что хочешь.


Делай что хочешь это мощно, я две страницы исписал тем чего я хочу, я не знаю КАК это сделать.
Да фиг с ним ,пусть будет Процесс . Начинаться он будет с заполнения заявки - заканчиваться выполненной заявкой.
состояний будет несколько:
1.Новая заявка (не сохранена и не выполнена)
2.заявка сохранена но не выполнена
3.заявка сохранена и выполнена
возможные варианты: 1-2,2-3,3-2
за переход между вариантами отвечает один метод process(), на вход которому я даю заявку и указываю что с ней делать (сохранить, выполнить, отменить). Метод process() делает одну вещь всегда - сохраняет заявку, а другую вещь (выполнить/отменить) делает только если его попросить об этом. Как мне завернуть каждый переход из состояния в состояние в отдельную транзакцию? это все что я хочу знать, ничего мне больше не нужно.
Если пошла аналогия с 1с, то мне нужен функционал , аналогичный сохранению документа с указанием режима проведения. И ничего больше, никаких журналов,проводок,последовательностей. В 1с это в транзакции, мне тоже надо в транзакции и все, только это.

Petro123,
Petro123
автор
ААААА!!!!! -мне результат нужен, мне безуууумно нужен результаааат. НО, если получить его я не могу, я хочу чтобы исходные данные остались в форме и все. Чтобы я мог открыть ее потом, и попробовать получить результат снова, не вводя никаких больше данных

IMHO это - ерунда


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

grasoff.net,
а вы на каком?

Petro123,

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

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

Petro123,
Спасибо, у меня к сожалению нет контейнера, чтобы использовать @TransactionAttribute(TransactionAttributeType.REQUIRED). Есть JAVA, есть Hibernate, есть мой долбаный метод, убираю свое требование(сохранение заявки в любом случае, даже если выполнение отвалилось) То есть метод = транзакция, откат = вернуть все как было. То есть по функционалу нужно ровно то же что вы написали - но имея только то что у меня есть.
Petro123Модель данных мне сложно делать на космос. На то она и МОДЕЛЬ.
а если не на космос то сделаете?

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


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

Petro123,
Petro123- если не на космос, то да:
выбирай
http://www.databaseanswers.org/data_models/
ох блин, тут целый день выбирать можно и не выбрать.

На красоту мне плевать. просто логика вряд ли изменится, а вот персист может и должен совершенствоваться. я просто не хочу при этом лезть и менять что-то в логике. это неправильно. Вдруг хибернейт начнет проводить опыты на кроликах, разумеется я сразу забью на него и приду к другому провайдеру, и мне придется лезть только в классы, оборачивающие персист, но никак не в мой многострадальный process(). про субд и вложенные транзакции мне хорошо известно. и про то что орм их не поддерживает - тоже.
Но вот я проглядел первый же ответ в теме:
BlazkowiczСессии и транзакции это не одно и тоже. Всегде можно обойтись без прямого доступа через менеджер и привязку к потокам. А управление транзакциями это вообще одна из задач бизнес-логики.
сессии и транзакции понятно что не одно и то же, а вот вторую часть предложения пожалуйста поясните, я не догнал пока как это реализовать, кажется это именно то что мне нужно. Примерно представляю так: обеспечить чтобы каждый мой сервисный метод типа MyPersist.save(MyEntity) использовал текущую сессию, и транзакцию открытую в этой сессии, вместо того чтобы начинать новую. Но тогда у меня появятся некоторые методы, способные начать новую транзакцию, и методы, лишенные такой возможности. Я сейчас возможно хрень написал, но она хотя бы рядом со смыслом цитаты или вообще далеко?

Petro123,
ой, проглядел
Petro123нет, я читаю, и помню, и у меня хорошая память. Просто я ответ отложил на потом (модель важнее).
Ответ - мешать логику с реализацией персиста - можно.

Если нет понятного и элегантного способа не мешать (без контейнера), то конечно буду мешать. Я просто надеялся что такой способ есть.

Насчет взглядов со стороны базы или кода, тут тоже полно нюансов. Не зная как может и как не может мапить хибернейт, можно облажаться с плясками от базы. А если начать от кода, можно получить на выходе монстра в базе. У меня получилось лажануться с обеих сторон.