it seems like quite a complicated example for my needs. I really just
wanted a simple way to view database data in JSF.
but i will try to push on...
BaseEntity implements two functions
public abstract Long getId();
public abstract Integer getOptlock();
my entities have id names like widget1Id, widget2Id, widget3Id. also i
have no such field as optlock. so how do i make a generic baseentity in
this case? do i need to include this in my database structure?
On 14/11/2016 23:03, Mark Struberg wrote:
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.
