Fixes are available
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21
APAR status
Closed as program error.
Error description
There is a scenario, albeit a very odd one, where by doing multiple 'merge' calls on the same unmanaged entity causes an exception. It is an 'odd' case because of the fact that an 'unmanaged' entity is being merged multiple times. The proper way to handle the scenario is to merge the managed instance. Here are some code snippets that can be used to explain the issue: @Entity @IdClass( LineItemPK.class ) public class LineItem { @Id @Column( name = "ORDER_ID", nullable = false ) private Long orderId; @Id @Column( name = "ITEM_ID", nullable = false ) private Long itemId; ...... @Embeddable public class LineItemPK implements Serializable { @Column( name = "ORDER_ID", nullable = false ) private Long orderId; @Column( name = "ITEM_ID", nullable = false ) private Long itemId; ...... @Entity @Table( name = "ORDER_TABLE" ) public class Order { @Id @Column( name = "ID", nullable = false ) private Long id; @OneToMany( fetch = FetchType.EAGER, cascade = CascadeType.ALL ) @JoinColumn( name = "ORDER_ID", referencedColumnName = "ID" ) private List<LineItem> items; ...... With these classes, take this test: em.getTransaction().begin(); Order order = new Order( 1l ); LineItem item = new LineItem( "my product", 44, 4.99f ); order.addItem(item); //NOTE: Notice that throughout the rest of the test the unmanaged order is //merged. Throughout the rest of the test we should do a //'order = em.merge(order)', or something to that effect (i.e. use the //'managed' order). However, technically speaking merging the unmanaged //order is not wrong, albeit odd and potentially error prone. em.merge(order); em.getTransaction().commit(); em.getTransaction().begin(); LineItem additional = new LineItem( "My second product", 1, 999.95f ); order.addItem(additional); order.setOrderEntry( new Date( System.currentTimeMillis() ) ); em.merge(order); //NOTE: do a flush here and all works fine: //em.flush(); em.merge(order); em.getTransaction().commit(); As you can see, the unmanaged order is merged. As my comments above suggest this is odd, but technically not wrong. What makes this case interesting is that if we change LineItem to use a single PK rather than a compound PK, all works fine! The issue can also be resolved by performing a strategic 'flush' as commented above. Furthermore, the exception the above test yields is: Caused by: <openjpa-2.1.2-SNAPSHOT-r422266:1686894M fatal general error> org.apache.openjpa.persistence.PersistenceException: Column 'ORDER_ID' cannot accept a NULL value. {prepstmnt 27085446 UPDATE ITEM_TABLE SET ORDER_ID = ? WHERE ORDER_ID = ? [params=(null) null, (long) 1]} [code=20000, state=23502] This is rather meaningless and is caused because OpenJPA executes this SQL when doing the third merge: openjpa.jdbc.SQL - <t 3968441, conn 30267242> executing prepstmnt 27085446 UPDATE ITEM_TABLE SET ORDER_ID = ? WHERE ORDER_ID = ? [params=(null) null, (long) 1] Given the odd message, and the fact that things work for the same exact scenario when a single PK is used, and the fact that it can be resolved with a 'flush', it makes sense to fix this issue. Finally, I can't stress enough that the proper way to perform the above test is to use the MANAGED version of the 'order'. In other words, replace all 'em.merge(order)' with 'order = em.merge(order)'. The above scenario creates far more SQL statements because of merging an unmanaged entity than if you merged a managed entity.
Local fix
The proper way to perform the above test is to use the MANAGED version of the 'order'. In other words, replace all 'em.merge(order)' with 'order = em.merge(order)'. The above scenario creates far more SQL statements because of merging an unmanaged entity than if you merged a managed entity.
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server V8.0.0, V8.5.0, and V8.5.5 who * * perform a 'merge' on an unmanaged entity * * multiple times. * **************************************************************** * PROBLEM DESCRIPTION: Merging an unmanaged entity multiple * * times can lead to nulls values being * * persisted, which can cause an * * exception. * **************************************************************** * RECOMMENDATION: * **************************************************************** Take the following code snippets: @Entity @IdClass( LineItemPK.class ) public class LineItem { @Id @Column( name = "ORDER_ID", nullable = false ) private Long orderId; @Id @Column( name = "ITEM_ID", nullable = false ) private Long itemId; ...... @Embeddable public class LineItemPK implements Serializable { @Column( name = "ORDER_ID", nullable = false ) private Long orderId; @Column( name = "ITEM_ID", nullable = false ) private Long itemId; ...... @Entity @Table( name = "ORDER_TABLE" ) public class Order { @Id @Column( name = "ID", nullable = false ) private Long id; @OneToMany( fetch = FetchType.EAGER, cascade = CascadeType.ALL ) @JoinColumn( name = "ORDER_ID", referencedColumnName = "ID" ) private List<LineItem> items; ...... With these classes, take this test: em.getTransaction().begin(); Order order = new Order( 1l ); LineItem item = new LineItem( "my product", 44, 4.99f ); order.addItem(item); //NOTE: Notice that throughout the rest of the test the //unmanaged order is merged. Throughout the rest of the //test we should do a 'order = em.merge(order)', or //something to that effect (i.e. use the 'managed' order). //However, technically speaking merging the unmanaged //order is not wrong, albeit odd and potentially error prone. em.merge(order); em.getTransaction().commit(); em.getTransaction().begin(); LineItem additional = new LineItem( "tst1", 1, 9.95f ); order.addItem(additional); order.setOrderEntry( new Date( System.currentTimeMillis() ) ); em.merge(order); //NOTE: do a flush here and all works fine: //em.flush(); em.merge(order); em.getTransaction().commit(); As can be seen with this code and test, the unmanaged order is merged multiple times. As the java comments above suggest this is odd, but technically not wrong. The java comments above explain how the issue can be resolved by merging the managed order. The issue can also be resolve by performing a strategic 'flush' as commented above. The exception the above test yields is: Caused by: <openjpa-2.1.2-SNAPSHOT-r422266:1686894M fatal general error> org.apache.openjpa.persistence.PersistenceException: Column 'ORDER_ID' cannot accept a NULL value. {prepstmnt 27085446 UPDATE ITEM_TABLE SET ORDER_ID = ? WHERE ORDER_ID = ? [params=(null) null, (long) 1]} This exception occurs because OpenJPA executes the following SQL when doing the third merge: openjpa.jdbc.SQL - <t 3968441, conn 30267242> executing prepstmnt 27085446 UPDATE ITEM_TABLE SET ORDER_ID = ? WHERE ORDER_ID = ? [params=(null) null, (long) 1] In this case, OpenJPA is attempting to persist 'null' to a column which is defined as not allowing non-null values. It should be noted that the proper way to perform the above test is to use the MANAGED version of the 'order'. In other words, replace all 'em.merge(order)' with 'order = em.merge(order)'. Furthermore, the above scenario creates far more SQL statements than is needed because it merging an unmanaged entity. Merging the managed entity in this test would produce fewer SQL statements than merging the unmanaged entity.
Problem conclusion
With this fix, code has been added to OpenJPA to ensure that OpenJPA doesn't attempt to persist a null value to a non-null column when an entity is merged multiple times. The fix for this APAR is currently targeted for inclusion in Service Levels (Fix Packs) 8.0.0.12 and 8.5.5.9 of WebSphere Application Server versions 8.0.0 and 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
PI47144
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-08-19
Closed date
2015-10-19
Last modified date
2015-10-19
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
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R800 PSY
UP
R850 PSY
UP
Document Information
Modified date:
27 April 2022