PM43511: JPA PERFORMANCE IMPROVEMENTS.

8.0.0.1: WebSphere Application Server V8.0 Fix Pack 1
8.0.0.2: WebSphere Application Server V8.0 Fix Pack 2
8.0.0.3: WebSphere Application Server V8.0 Fix Pack 3
8.0.0.4: WebSphere Application Server V8.0 Fix Pack 4
8.0.0.5: WebSphere Application Server V8.0 Fix Pack 5
8.0.0.6: WebSphere Application Server V8.0 Fix Pack 6
8.0.0.7: WebSphere Application Server V8.0 Fix Pack 7
8.0.0.8: WebSphere Application Server V8.0 Fix Pack 8
8.0.0.9: WebSphere Application Server V8.0 Fix Pack 9
8.0.0.10: WebSphere Application Server V8.0 Fix Pack 10
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15

APAR status

• Closed as program error.

Error description

• Under certain circumstances, Java Persistence API
  (JPA)scalability and performance is not optimal.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server V8.0                                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: Under certain scenarios, Java           *
  *                      Persistence API (JPA) scalability and   *
  *                      performance can be improved.            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  One new high performance feature was added by this APAR and a
  number of issues were resolved.
  

Problem conclusion

• Under some circumstances, when running against DB2, the JPA
  runtime will call back to the database when an exception
  is encountered to build a more meaningful exception message.
  This APAR adds the property
  openjpa.jdbc.DBDictionary=db2(AppendExtendedExceptionText=false)
  which will reduce the database load by not going back to the
  database for the extended text.
  
  When persisting an Entity with a relationship that has cascade
  = CascadeType.PERSIST set, the JPA runtime will run an extra
  query to see if the cascaded relationship is detached and
  already exists in the database. A new property was added
  (openjpa.Compatibility(CheckDatabaseForCascadePersistToDetachedE
  ntity=false) ) to tell the runtime to omit this extra query.
  In the event that the related type already exists in the
  database, an EntityExistsException will be thrown. Throwing an
  exception in this scenario is compliant with the JPA 2.0
  specification.
  
  The detach processing resulting from the closure of an
  EntityManager for Entities that will not be used any longer
  can be improved by setting the following property:
  openjpa.DetachState=loaded(LiteAutoDetach=true,DetachProxyFields
  =false). A new attribute of this property, DetachProxyFields,
  notifies the JPA runtime to leave proxies in place.
  
  When the JPA runtime is loading an Entity and if it owns a
  lazy relationship to another Entity, the lazy Entity will be
  loaded from the persistence context (L1 cache) and if
  configured, the ObjectCache. Set the following property to
  enable this function :
  wsjpa.BrokerImpl=com.ibm.ws.persistence.kernel.WsJpaBrokerImpl(C
  heckCacheForLazyFields=true).
  
  A new feature was added that allows the runtime to eagerly
  pre-load the ObjectCache. When running with a pre-loaded
  ObjectCache many of the Entity restrictions that were in place
  are lifted. For example, it is now valid to put Entities in
  the ObjectCache that have relationships to other Entities.
  Note, all related types must also be configured to be in the
  ObjectCache. Please review infocenter documentation for
  complete details.
  
  The JPA runtime was fixed so that specifying the fetch type
  for a relationship in a xml mapping file (orm.xml) will be
  honored. For example, previously if a OneToOne relationship
  used the default fetch type (EAGER) and you tried to mark the
  relationship as LAZY via the orm.xml file, the JPA runtime
  would not honor that setting. This is now fixed.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 8.0.0.1.  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 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

• R800 PSY

     UP