IBM Support

PI19732: FIRST JPQL WITH LEFT JOIN FETCH FOR LAZY LOADED SPECIFIED AND DATA CACHE ENABLED. SUBSEQUENT DOES NOT GET LOADED.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • OPEN JPA JIRA  OPENJPA-2508:
    
    In a simple JPQL with left join fetch for a lazy loaded
    association specified and data cached enabled, first time the
    query executed, the lazy loaded association get loaded,
    returned and cached. Subsequent invocation of the same query
    does NOT "load" and return the association from the query
    invocation.
    
    The test case call doQuery() twice, i.e. same call path. The
    first call executes the SQLs and fetches Dept and Employee from
    the db. Both dept and employee were cached. The second call the
    Employee was fetched from cache but the Employee.dept remains
    null even the SQL requests to load dept using "join fetch dept".
    
    The attached test will pass (Employee.dept is loaded; not null)
    if either:
    1) the Employee.dept is marked FetchType.EAGER, or
    2) TestNPE2.doquery().... em.detach(emp) is removed.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server V8.5.0 and V8.5.5 who make use of    *
    *                  JPA Criteria and OpenJPA QueryCache.        *
    ****************************************************************
    * PROBLEM DESCRIPTION: When a JPQL with 'LEFT JOIN FETCH' is   *
    *                      run and OpenJPA DataCache is enabled,   *
    *                      incorrect results are returned.         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When the OpenJPA DataCache is enabled (that is,
    openjpa.DataCache=true), there exists an issue where
    association data for a JPA entity is not loaded when
    performing left fetch joins.  To illustrate this issue lets
    look at snippets of sample code.  Take this JUnit test where
    Department entity has a OneToMany relationship with the
    Employee entity:
    private void doQuery(EntityManagerFactory emf) {
    String query = "select o from Employee o " + "left
    join fetch o.dept " + "where o.dept.deptno = 10";
    EntityManager em = emf.createEntityManager();
    List<Employee> emps = em.createQuery(query,
    Employee.class).getResultList();
    //There are 4 employees and 2 departments in the
    database, 2 employees per department.
    Assert.assertEquals(4, emps.size());
    for (Employee emp : emps) {
    em.detach(emp);
    Assert.assertNotNull(emp.getDept());
    Assert.assertEquals(2,
    emp.getDept().getEmployees().size());
    }
    em.close();
    }
    With this test, the first run works fine.  Notice that
    'left join fetch' is used in the query.  The first time this
    test is run the associations get loaded, returned, and
    cached (since DataCache is enabled).  When the test is called
    a second time (under the same EntityManagerFactory), query
    does not return the Department association
    

Problem conclusion

  • With this fix, code has been added to OpenJPA to ensure the
    proper results are returned from a JPQL query with 'LEFT JOIN
    FETCH' and OpenJPA DataCache is enabled.
    
    The fix for this APAR is currently targeted for inclusion in
    Service Level (Fix Pack) 8.5.5.5 of WebSphere Application
    Server version 8.5.5.
    
    Please refer to the recommended updates page for delivery
    information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI19732

  • Reported component name

    WEBSPHERE APP S

  • Reported component ID

    5724J0800

  • Reported release

    850

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-06-10

  • Closed date

    2014-09-25

  • Last modified date

    2014-09-25

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WEBSPHERE APP S

  • Fixed component ID

    5724J0800

Applicable component levels

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.5","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
27 April 2022