EAGER vs. LAZY loading - weird behaviour in OpenJPA 1.0.1

[Beniamin Mazan]

Hi
I refactored my source code quoted in
http://n2.nabble.com/Incredible-set-of-statements-td221053.html
Currently I use:

@Entity
public class Customer {
...
        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy =
"customer")
        private Set<Product> products = new HashSet<Product>();
...
}

@Entity
public class Product {
...
    @ManyToOne(cascade = { CascadeType.MERGE, CascadeType.REFRESH }, fetch =
FetchType.EAGER)
    @JoinColumn(name = "billacc_id", nullable = false)
    Customer customer;

    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy
= "product")
    @OrderBy(value = "created DESC")
    private List<RequestLog> logs = new ArrayList<RequestLog>();
...
}

@Entity
public class RequestLog {
...
        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.LAZY)
        @JoinColumn(name = "product_id", nullable = false)
        private Product product;

        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy =
"request")
        @OrderBy(value = "created DESC")
        private List<ResponseLog> children = new ArrayList<ResponseLog>();
...
}

@Entity
public class ResponseLog {
...
        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.LAZY)
        @JoinColumn(name = "request_id", nullable = false)
        private RequestLog request;
...
}

I've noticed 2 cases of outlandish manner.

1) When I use finder for Customer or Product (with RequestLog.product using
fetchType == LAZY) I got initialized structure with all RequestLogs'
references to Products set to null

2) When I use finder for Customer or Product (with RequestLog.product using
getchType == EAGER) I see that OpenJPA generate queries to get Customer,
Product, RequestLog from DB, but queries for RequestLogs are joins using all
classes from bottom to up - (request_log, product and customer) despite the
fact, that EM has gathered these data in previous queries and could use it
instead of redundant selecting them from DB.

Is it usual OpenJPA behaviour?

-----
thanks, Beniamin
My homesite -  http://www.mazan.pl http://www.mazan.pl 
--
View this message in context: http://n2.nabble.com/EAGER-vs.-LAZY-loading---weird-behaviour-in-OpenJPA-1.0.1-tp364201p364201.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

[Ignacio Andreu]

As far as I know, if you use the eager strategy is normal that OpenJPA
generates queries to load the diferent relations from the database. If you
use lazy strategy OpenJPA only loads the relations when they are acceded, of
course if you are handling the PersistentContext for your own and you closed
it before the access it will be null.

On Tue, Jul 8, 2008 at 1:56 PM, Beniamin Mazan <it@...> wrote:

>
> Hi
> I refactored my source code quoted in
> http://n2.nabble.com/Incredible-set-of-statements-td221053.html
> Currently I use:
>
> @Entity
> public class Customer {
> ...
>        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER,
> mappedBy =
> "customer")
>        private Set<Product> products = new HashSet<Product>();
> ...
> }
>
> @Entity
> public class Product {
> ...
>    @ManyToOne(cascade = { CascadeType.MERGE, CascadeType.REFRESH }, fetch =
> FetchType.EAGER)
>    @JoinColumn(name = "billacc_id", nullable = false)
>    Customer customer;
>
>    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy
> = "product")
>    @OrderBy(value = "created DESC")
>    private List<RequestLog> logs = new ArrayList<RequestLog>();
> ...
> }
>
> @Entity
> public class RequestLog {
> ...
>        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch
> =
> FetchType.LAZY)
>        @JoinColumn(name = "product_id", nullable = false)
>        private Product product;
>
>        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER,
> mappedBy =
> "request")
>        @OrderBy(value = "created DESC")
>        private List<ResponseLog> children = new ArrayList<ResponseLog>();
> ...
> }
>
> @Entity
> public class ResponseLog {
> ...
>        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch
> =
> FetchType.LAZY)
>        @JoinColumn(name = "request_id", nullable = false)
>        private RequestLog request;
> ...
> }
>
> I've noticed 2 cases of outlandish manner.
>
> 1) When I use finder for Customer or Product (with RequestLog.product using
> fetchType == LAZY) I got initialized structure with all RequestLogs'
> references to Products set to null
>
> 2) When I use finder for Customer or Product (with RequestLog.product using
> getchType == EAGER) I see that OpenJPA generate queries to get Customer,
> Product, RequestLog from DB, but queries for RequestLogs are joins using
> all
> classes from bottom to up - (request_log, product and customer) despite the
> fact, that EM has gathered these data in previous queries and could use it
> instead of redundant selecting them from DB.
>
> Is it usual OpenJPA behaviour?
>
> -----
> thanks, Beniamin
> My homesite -  http://www.mazan.pl http://www.mazan.pl
> --
> View this message in context:
> http://n2.nabble.com/EAGER-vs.-LAZY-loading---weird-behaviour-in-OpenJPA-1.0.1-tp364201p364201.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

[Beniamin Mazan]

Ignacio Andreu wrote:
>
> As far as I know, if you use the eager strategy is normal that OpenJPA
> generates queries to load the diferent relations from the database. If you
>

You're right of course. But OpenJPA generate queries to load object that are
already loaded. For example if loading Product causes loading RequestLog I
expected that OpenJPA has no need to query for Product which is owner of
RequestLog and is loaded to Context. Especially when I use bi-directional
relation.
Am I wrong ?

-----
thanks, Beniamin
My homesite -  http://www.mazan.pl http://www.mazan.pl 
--
View this message in context: http://n2.nabble.com/EAGER-vs.-LAZY-loading---weird-behaviour-in-OpenJPA-1.0.1-tp364201p364227.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.