используется jsf
для примера есть 2 класса, user и car, то есть один юзер имеет много машин, ну и каждая машина имеет еще много фсего в отдельной таблице, для этого сделал у нее свой id и id юзера







нужно добавить новую машину к юзеру
вытаскиваю юзера из сессии и  
 
...
один раз вроде добавляется ок, но потом Cannot persist detached object User, бывает и тоже самое для Car
как понимаю нужно перед каждым persist делать сначала find для этого обьекта. но и он тоже выдает такую же ошибку,
как правильно работать с этими персистанс обьектами ?

спасибо


  

Это сообщение отредактировал(а) aol - 23.10.2008, 21:49

Я вобще - то этой спецификацией не пользуюсь, но кажется: persist используется при создании, дальше работает merge .

merge вроде для update можно использовать, не уверен
но он тоже не работает
на форуме забугорном читал что persist да и по спецификации jpa, обьекты должны быть new, то есть новые перед каждым persist и тд.. но как их вытащить если em.find(Car.class, id) например тоже выдает ошибку такую.

Не может find такую же ошибку выдавать. Максимум IllegalArgumentException может выдать. 
Метод merge так же как и метод persist сохраняет новый объект, если он действительно новый. Из спецификации:


Приведите ваш код полностью.

прикрепил атачем, много там кода для страницы мне показалось.
класс Contract связан через форегн кей c User, работает отлично, при попытке сделать у контракта свой id и добавить поле с userId опять лезут ошибки
JPABean `инджектиться` через faces-config.xml




Присоединённый файл ( Кол-во скачиваний: 5 )
 model.zip 5,63 Kb

Во-первых, если Вы используете EJB 3.0, то почему не инжектируете через @PersistenseContext? Быть может лучше доверить управление транзакциями контейнеру?

Во вторых, заметил у Вас часто используются подобные строки кода:


Во-вторых, зачем делать refresh после find, да еще и в отдельной транзакции? Потом, каждый раз перед новой операцией (что было также замечено в коде) создавая новый EntityManager, Вы рискуете попасть на  тот самый "detached object exception". Поскольку объект изначально был загружен в другом контексте, а значит связан с ним (с другим контекстом). При попытке вызова persist на detached объекте будет выброшено EntityExistsException. Решать такую проблему можно работая с одним экземпляром EntityManager в пределах всей бизнес-операции, т.е. методы для поиска/добавления/изменения на одном и том же экземпляре EntityManager в пределах одного (а иногда и нескольких) запросов.




 

refresh в бине ContractManager в методе findContract для того чтобы после find, обновился обьект contract, так как если в базе например вручную изменить поле в данном случае готовности контракта, то без refresh он не обновляется и на экране видны старые данные.
а то что не на том месте, так это я ошибся,
наверное так надо было


про EntityManager не знал что нужен один для всех, поэтому я JPABean закешировал путем помещения в файле faces-config.xml



и 



а потом просто брал в бинах у которых это есть это свойство



то есть мне нужно просто перенести в эти бины обьект EntityManager, и как так обьявить ?


..






Это сообщение отредактировал(а) powerOn - 25.10.2008, 00:12

Это весьма тонкий вопрос, относящийся к параллельно выполняемым задачам. Существует ряд проблем, если планируется что несколько потоков будут одновременно использовать одни данные, например Repetable Read или Phantom Insert. Они разрешается выставлением правильного уровня изоляции для транзакционного ресурса или/и блокировками. Посмотрите вот эту статейку.



К сожалению, с JSF я достаточно давно работал и успел его подзабыть. Но предполагаю, что JavaEE5 контейнер должен инжектировать EJB компоненты в JSF бины через @EJB аннотацию (вроде в JSF 1.2 это получалось). Если это так, то вам следует пойти таким путем. При этом EntityManager так же будет инжектирован в Ваши EJB. Транзакции открывать и закрывать самостоятельно не нужно, это сделает за Вас контейнер. Посмотрите аннотации @TransactionAttribute.

не очень понял про инжектировать EJB компоненты в JSF бины. 
попробую описать как работает схема сейчас.

есть в faces-config.xml следущие записи

WelcomeBean просто класс в котором есть поле типа СontractBean

 

в свою очередь ContractBean содержит в себе 2 поля, contractManager как раз для работы с бд и Сontract - а это сам @Entity который и сохраняется

  

ContractManager имеет поле типа JPABean 

  

а JPABean имеет жизненый цикл application, то есть живет пока сервак не умрет

  

а он просто вот что 



на jsf есть такие выражения 


когда с jsf, вызывается метод например #{WelcomePage.contractBean.createContract}
то бины и их поля которые описаны данным образом в faces-config.xml создаются так называемым путем инжектирования, 

то есть бин ContractManager имеющий у себя поле типа 

private JPABean jpaBean 
и его сеттеры и геттеры 
public JPABean getJpaBean() { return jpaBean; }
public void setJpaBean(JPABean jpaBean) { this.jpaBean = jpaBean; }

после вызова соответсвующей jsp, может обращаться у своему свойству jpaBean, что я и делаю для записи обьекта в бд, получив от jpaBean
EntityManager, EntityManager em = jpaBean.getEMF().createEntityManager();

а раз Вы говорите что EntityManager нужен для всех один, то значит мне просто нужно перенести сам EntityManager 
в бин который общается с бд, ContractManager 

@PersistenseContext
EntityManager em;

то есть эта запись равносильна EntityManager em = jpaBean.getEMF().createEntityManager(); или если напрямую то 
EntityManager em = Persistence.createEntityManagerFactory("portalJPA"); - что описано в persistace.xml ?

прощу прощения что так фсе подробно, просто сам пытаюсь понять как это все должно работать )




Это сообщение отредактировал(а) aol - 25.10.2008, 01:10

Точно так же как Вы инжектируете EntityManager в EJB компоненты с помощью аннотации @PersistenseContext, Вы можете инжектировать EJB компоненты в BackingBean-ы JSF. Проведите аналогию с инжектированием, которое происходит с JSF бинами, но только не нужно писать xml конфигурацию, контейнер получит всю необходимую информацию из аннотаций.

Еще как вариант, самостоятельно создавать новый EntityManager (как это у Вас и было), но в request scope бине. При придется самостоятельно следить за транзакциями (открывать, закрывать), а во время Unit такой подход будет лишней палкой в колесе.




Да, при этом имя персистент юнита можно указать в аннотации @PersistenseContext(unitName="portalJPA").

до конца не понимаю тогда в чем будет разница, то что я сейчас создаю EntityManager из обьекта который висит постоянно в application, и что если я перенесу создание EntityManager  в сам бин только через аннотацию, то есть это одно тоже ?, и ошибка так же вылетать?

или вот еще, может тогда перенести EntityManager  в JPABean который в application, то есть он будет возвращать не EntityManagerFactory, а сразу EntityManager, причем всегда один и тот же, так как закеширован.. так правильно вообще делать ?

Это сообщение отредактировал(а) aol - 25.10.2008, 01:53

В application scope его не следует создавать, ведь так к нему будут обращаться потоки параллельно из нескольких запросов, что есть плохо. Желательно, сто бы каждый request имел свой EntityManager. На крайний случай можно создавать его в Session scoped бине, но только если этого требует логика.



Если будете сами создавать EntityManager, то

ага, то есть если в бине будет 
@PersistenseContext(unitName="portalJPA")
EntityManager em;
то это значит что я его не сам создаю ?

то есть это не совсем одно и тоже как было раньше 
EntityManager em = jpaBean.getEMF().createEntityManager();

совершенно верно. его создаст контейнер и инжектирует в бин.

p.s.: только что попробовал создать ear проект который содержит ejb модуль с EJB бином и web модуль с JSF страницей и managed bean-ом. EJB в JSF бины инжектируются, проверено.

убрал из всех бинов которые писали в бд

и добавил к ним поле 

из faces-config.xml тоже убрал все записи про JPABean
при попытке деплоя ear такая вот ошибка

Deploying application in domain failed; The persistence-context-ref-name [portal.db.ContractManager/em] in module [] resolves to a persistence unit called [portalJPA] which is of type RESOURCE_LOCAL. Only persistence units with transaction type JTA can be used as a container managed entity manager. Please verify your application.

вот мой persistance.xml


Это сообщение отредактировал(а) aol - 25.10.2008, 02:48

под утро уже не вижу что сервак хочет )
фсе деплоиться хорошо, но вот при доступе к базе, теперь фсегда ошибка java.lang.IllegalStateException

да, и то есть теперь необходимости нет в постоянно
      em.getTransaction().begin();
      em.persist(user);
      em.getTransaction().commit();

нужно сразу 
      em.persist(user);
или
      em.refresh(user);
или тд..

поменяйте в persistance.xml:


на





Да, теперь не нужно вызывать  em.getTransaction().begin(); или em.getTransaction().commit();. Commit произойдет автоматически. А что бы откатит транзакцию, придется получить ссылку на SessionContext через инъекцию:

и вызывать


И еще, не забудьте использовать аннотации @TransactionAttribute на методах EJB, что бы отметить необходимую логику транзакции.

на JTA уже поменял

как понимаю sessionContext.setRollbackOnly();
должно быть в блоке catch/finally метода где persist.()
@TransactionAttribute тоже на методах где просходит persist.().. ?

Зависит от логики работы программы. Если при таких условиях нужно откатывать транзакцию, то да.



Почитайте в документации об аннотации @TransactionAttribute и её параметрах. Так же проанализируйте логику вашей программы, где и как должны работать транзакции.  Уже в зависимости от этого, расставляйте аннотации. В частности, для persists() транзакция вам точно потребуется.

методы проаннотировал как @TransactionAttribute(value = REQUIRES_NEW)
получаю ошибку javax.persistence.TransactionRequiredException

заметил что ошибка возникает на persis, find, тд..
на запросах типа  Query query = em.createNamedQuery("findUserByEmail"); все нормально

    

а если REQUIRED попробовать? (ну или @TransactionAttribute без параметров указать, тогда будет выставлен тип REQUIRED по умолчанию).

делал по разному, и REQUIRED  и без параметров тоже

у меня такой код отработал без ошибок:



Добавлено через 4 минуты и 20 секунд
Кстати, смотрел непосредственно в БД, новая запись там появляется. Т.е. persist и commit отрабатывают.

да, тоже самое, только без implements Local
быть может что то не инджектиться, но что и когда не знаю

Ваш EJB компонент должен имплементировать локальный интерфейс. У меня было сделано так:


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

добавил




в классе
public class UserAuthBean {
,методы которого вызываются с jsf
пробовал описать

private UserManager userManager;
if(userManager.addUser(user)) {...

так и 

private UserManagerLocal userManager;
if(userManager.addUser(user)) {...

получаю javax.persistence.TransactionRequiredException

возможно нужно что то еще проаннотировать.

нужно ли аннотировать

public class UserAuthBean {
@EJB
private UserManager userManager; ?





Это сообщение отредактировал(а) aol - 26.10.2008, 14:40

Если EJB создан как:



в бине JSF пишется инъекция таким образом:

получаю вот что теперь 
com.sun.enterprise.deployment.backend.IASDeploymentException: Error loading deployment descriptors for module [Web] -- Error: Unresolved <ejb-link>: UserManager
или теперь нужно фсе entity описать в ejb-jar.xml ?
немного не понимаю что происходит

А что Вы кстати деплоите? И на какой сервер.
У меня ear архив, который содержит jar с EJB компонентами и war с web-приложением.
Прикрепил свой проект (для NetBeans IDE).






Присоединённый файл ( Кол-во скачиваний: 7 )
 EnterpriseApplication1.zip 45,21 Kb

сервер sun app server, деплою из идеи, ear, идея помещает файл ear в каталог сервера autodeploy.
по смыслу вроде тоже самое что и у вас. 
разницу увидел в том, что у меня jsf страница вызывает методы у своего бина, который в свою очередь вызывает промежуточный бин у которого есть @EJB(beanName = "UserManager") а уже он обращается к UserManager

пробовал деплоить вручную из вебконсоли, ошибка при деплое war 
Deploying application in domain failed; Error loading deployment descriptors for module [Web] -- Error: Unresolved : UserManager Error loading deployment descriptors for module [Web] -- Error: Unresolved : UserManager 

выслал вам на email, может там виднее )
сюда не помещается

Это сообщение отредактировал(а) aol - 26.10.2008, 19:51

У меня такая ошибка возникает если модули EJB и WAR деплоить по отдельности.

Добавлено через 1 минуту и 31 секунду
сейчас посмотрю Ваши наработки.

Я посмотрел исходники и не совсем понял, что же получается после сборки. Такое ощущение, что это архив со структурой war-файла, а не ear с двумя отдельными модулями. Почему-то классы EJB и JSF бинов находится в одной подпапке исходников. Вышлите то, что получится после сборки.

Добавлено через 4 минуты и 24 секунды
прикрепил свою сборку

Присоединённый файл ( Кол-во скачиваний: 6 )
 EnterpriseApplication1.ear 11,34 Kb

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