openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: fetching associations
Date Mon, 14 Nov 2016 22:03:11 GMT
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.broadhead@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.broadhead@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.broadhead@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.
>>> 


Mime
View raw message