-
1. Re: Seam + JPA performance problems
diegocoronel Jul 4, 2008 5:14 PM (in response to securez)Maybe its happening because you are probably using EAGER in all entities, this makes hibernate load all your data(including OneToMany, ManyToOne). Using seam is possible to use LAZY and not worry about lazyInitializationExcepion, you should try some LAZY mapping to optimize you performance.
-
2. Re: Seam + JPA performance problems
dan.j.allen Jul 7, 2008 8:17 AM (in response to securez)You should almost never use EAGER. A case for using EAGER would perhaps be an employee with multiple e-mail addresses where the collection of Email entities is virtually part of the Employee entity. If you want to do joins, they should be done in JPQL. Otherwise, you are just asking for trouble.
select e from EnlaceOba e join fetch e.nodeOrigin
-
3. Re: Seam + JPA performance problems
securez Jul 7, 2008 10:47 AM (in response to securez)I change the model clasess to use LAZY loading for many-to-one relations that i have, so when i edit the data, ok a simple select is issued, but a lot of selects are issued to qet the object that will displayed selected in the selectOne JSF control.
My question is, why query this two times, the render of the selectOne will query all posible values from database, so query it again makes no sense.
How can i avoid this?
-
4. Re: Seam + JPA performance problems
dan.j.allen Jul 8, 2008 11:29 PM (in response to securez)You need to use the fetch join that I proposed above. This would be done in a factory:
@Factory("enlaceObaList") public List<EnlaceOba> fetchEnlaceObaList() { return entityManager .createQuery("select e from EnlaceOba e join fetch e.nodeOrigin") .getResultList(); }
Yes, it is going to do n+1 select if you don't use eager fetching on a query, but you don't want eager fetching on your entities.
-
5. Re: Seam + JPA performance problems
admin.admin.email.tld Jul 9, 2008 1:04 AM (in response to securez)I'll agree with Dan on this. Using the @Factory method and a JPA query with fetch join will solve your problem. The @Factory method only gets executed if the value of @Factory is null. Due to the nature of the JSF lifecycle, the getter/setter and action methods in the JSF EL that point to the SFSB are executed too many times in some cases, so you need to check for null, otherwise you'll end up with excessive processing and transactions (i.e. performance hits).
refer to section 13.2 Selecting a fetch strategy and pgs. 649-650 of Bauer and King book for more on when to use eager vs. lazy and fetch joins.
Here's the main point from section 13.2.5:
If you switch from the default strategy to queries that eagerly fetch data with joins, you may run into another problem, the Cartesian product issue. Instead of executing too many SQL statements, you may now (often as a side effect) create statements that retrieve too much data.
You need to find the middle ground b/n the two extremes: the correct fetching strategy for each procedure and use case in your application.