Hi Matthew! EclipseLink seems to open a new connection for lazy loading by using a new temporary EntityManager and Transaction. And no XA transaction afaik. Of course this is by far not a portable behaviour as neither Hibernate nor OpenJPA support this. I also have no clue how it behaves in case of an OptimisticLockException. I mean the lazy loading can literally happen a few minutes later...
Whether to go back to EclipseLink is a question on how your whole application looks like. You did use a non-portable feature and of course it is now a bit harder to switch providers. But it's not impossible. The usual solution is to keep the EntityManager open for the whole request. How big is your app and how old is the codebase? Do you use XA or resource-local? Does it use many EJBs or do you already mainly use CDI? In case of the later you can use a @RequestScoped EntityManager + DeltaSpike @Transactional for example. https://deltaspike.apache.org/documentation/jpa.html Sample code With XA (JTA): https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java#L35 https://github.com/struberg/lightweightEE/blob/jtacdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java https://github.com/struberg/lightweightEE/blob/jtacdi11/backend-api/src/main/resources/META-INF/persistence.xml#L9 https://github.com/struberg/lightweightEE/blob/jtacdi11/gui/src/main/tomee/conf/tomee.xml With ResourceLocal: https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/impl/EmployeeServiceImpl.java https://github.com/struberg/lightweightEE/blob/cdi11/backend/src/main/resources/persistence-CaroLine.properties https://github.com/struberg/lightweightEE/blob/cdi11/backend-api/src/main/resources/META-INF/persistence.xml I also wrote a few blog posts which might help you understand this topic, e.g. https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/ Of course the entitymanager-per-request pattern also has a few limitations, e.g. if cannot lazy load data in subsequent responses (data has to be rendered during the initial request). But it's rather easy to prevent such a scenario. Usually you will only use Entities in CRUD dialogues anyway. I would e.g. _not_ use the entities in DataTables on a search dialogue. In that case I'd rather use a dedicated list item via SELECT NEW. This is much faster, has way less memory overhead and also will prevent you from a lot optimistic locking pain. Feel free to ask more questions, this is a rather complex and often not well enough understood topic. LieGrue, strub > Am 14.11.2016 um 20:12 schrieb Matthew Broadhead > <matthew.broadh...@nbmlaw.co.uk>: > > so if the managedbean is not an ejb anymore and therefore the transaction is > closed how does it work for eclipselink? do they use some magic? are there > any plans for implementing this "feature" in the future? after spending a > few months migrating to myfaces and openjpa on the suggestion of romain i now > find that openjpa cannot lazy load entities from jsf which is fairly > disappointing to say the least. is my best route to go back to eclipselink? > > On 09/11/2016 17:40, Mark Struberg wrote: >> Oki all clear. The internal EntityManager will get closed when you leave the >> outer @Stateless method. >> @Stateless EJBSs really are nothing else than beans with an interceptor >> which opens and commits the transaction and EntityManager on the outermost >> EJB level. >> >> Since the @ManagedBean is not an EJB anymore you don't have any transaction >> nor EntityManager open anymore in your render_response phase in JSF. Which >> means that OpenJPA cannot provide lazyloading for you. >> >> I personally prefer to use the entitymanager-per-request patter and using >> CDI with a @RequestScoped EntityManager. But that might be a bigger change >> in architecture for you. >> Other options are: >> >> * touching the required bits in your DAO >> >> * using eager fetching >> * using a fetch-plan >> * using DTOs >> >> LieGrue, >> strub >> >> >> >> >> >>> On Wednesday, 9 November 2016, 17:31, Matthew Broadhead >>> <matthew.broadh...@nbmlaw.co.uk> wrote: >>>> sorry for the delay in replying i was very busy >>> as a simple example there is a generic Dao class to return the results >>> of a namedquery >>> @Stateless >>> public class DAO { >>> @PersistenceContext(unitName = "widgetDataSource") >>> private EntityManager em; >>> .... >>> @SuppressWarnings("unchecked") >>> public <E> List<E> namedFind(Class<E> clazz, String >>> query) { >>> return em.createNamedQuery(query, clazz).getResultList(); >>> } >>> .... >>> } >>> call the namedFind from another stateless >>> @Stateless >>> public class WidgetDAO { >>> @EJB >>> private DAO dao; >>> ... >>> public List<Widget> findAll() { >>> return dao.namedFind(Widget.class, "Widget.findAll"); >>> } >>> .... >>> } >>> this is loaded into a managedbean >>> @ManagedBean >>> @ViewScoped >>> public class WidgetBean { >>> @EJB >>> private WidgetDAO widgetDao; >>> private List<Widget> widgetList; >>> public void onload(){ >>> setWigdetList(widgetDao.fildAll()); >>> } >>> ...setter getter of widgetList >>> } >>> which is supposed to display in jsf >>> <?xml version="1.0" encoding="UTF-8"?> >>> <ui:composition xmlns="http://www.w3.org/1999/xhtml"; >>> xmlns:h="http://java.sun.com/jsf/html"; >>> xmlns:ui="http://java.sun.com/jsf/facelets"; >>> xmlns:f="http://java.sun.com/jsf/core"; >>> template="/WEB-INF/include/layout.xhtml"> >>> ... >>> <ui:repeat var="widget" >>> value="#{widgetBean.widgetList}"> >>> <ui:repeat var="subWidget" >>> value="#{widget.subWidgets}"> >>> ...where are the sub widgets? >>> </ui:repeat> >>> </ui:repeat> >>> </ui:composition> >>> >>> Like i say if i loop through the widgets (or maybe the subwidgets as >>> well) it then loads in the JSF. so it lazy loads in java but not in >>> JSF. should i change to eager when i generate the entities or is there >>> something else i can do? is it supposed to work the same as eclipselink? >>> >>> >>> On 02/11/2016 08:06, Mark Struberg wrote: >>>> Hi Matthew! >>>> >>>> Now I'm back on my notebook. >>>> What transaction mechanism are you using? JTA or ResourceLocal? >>>> And what technology to control the transactions? EJBs? CDI? Spring? >>>> >>>> It boils down to be more a question about appliction architecture than >>> about OpenJPA, but still very important to cover. So just go ahead, I'm >>> pretty sure we can help you. >>>> LieGrue, >>>> strub >>>> >>>>> Am 24.10.2016 um 10:34 schrieb Matthew Broadhead >>> <matthew.broadh...@nbmlaw.co.uk>: >>>>> HI, I am using TomEE 7.0.1 and I just switched from Plume to Plus. I >>> was using eclipselink and now I am converting to OpenJPA. When I fetch a >>> set of >>> entities and then try to iterate through their associations in JSF the list >>> is >>> empty. in eclipselink they were populated by default. if i loop through >>> the >>> entities in Java before displaying in JSF then they are populated (i guess >>> they >>> get lazy loaded). is there a setting that needs to be changed? like >>> generating >>> with all associations as eager or setting a flag in persistence.xml? what >>> would >>> give the same default as eclipselink? seemed like an easy question but i >>> could >>> not find anything by searching. >>>
