PM41128: JIRA OPENJPA-1691 DEFECT BACKPORTED TO V7 OPENJPA 1.2.X

Fixes are available

APAR status

Closed as program error.

Error description

When using OpenJPA and persisting more than 4000 charaters to
an Oracle XMLType the customer sees the following exception:

ORA-01461: can bind a LONG value only for insert into a LONG
column

Local fix

```
N/A
```

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server V7.0.0 and V8.0.0 who make use of    *
*                  Oracle XMLType columns and attempt to       *
*                  store more than 4000 charaters in the       *
*                  column.                                     *
****************************************************************
* PROBLEM DESCRIPTION: Oracle XMLType column failed to         *
*                      insert/update when xml contains more    *
*                      than 4000 characters.                   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Oracle throws the following exception when XML content is
greater than 4000 characters:
ORA-01461: can bind a LONG value only for insert into a LONG
column.
This exception is due to the way OpenJPA retrieves the XML
data from the Oracle database (i.e. it uses a 'getStringVal'
method on the JDBC driver).

Problem conclusion

With this fix, code has been added which allows OpenJPA to use
a Reader-based JDBC 4.0 method to set XML data.  This allows
XMLType values larger than 4000 characters to be successfully
updated or inserted.

There are a number of restrictions for this fix, as will be
described now.
The code for the fix requires an Oracle JDBC 4.0 level driver
(e.g. ojdbc6.jar).  Also note that it is not enough to simply
get the Oracle JDBC 4 drivers, but the Oracle DB version must
also support the JDBC 4 drivers and contain the code to allow
XML content greater than 4000 characters (e.g. driver version
11.2.0.1.0).

On WebSphere Application Server V7.0.0, the code changes
are gated (enabled/disabled) via a system property. On
WebSphere Application Server V8.0.0, the code changes
are applied by default, and the system property described
shortly should be removed from any application which used the
property on V7.0.0; setting the property on V8.0.0 will result
in a warning message.  The system property is named
'supportsSetClob' and is defined on OpenJPA's Oracle
dictionary class. As an example, the property can be defined
as follows in a persistence.xml file:

<property &#130; &#160;name="openjpa.jdbc.DBDictionary" &#130; &#160;value="oracle(s
sSetClob=true)"/> &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;


Next, it should be noted that OpenJPA code expects the &#130; &#160;XML
field(s) &#130; &#160;to &#130; &#160;be &#130; &#160;annotated &#130; &#160;with the following: &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
@Strategy("org.apache.openjpa.jdbc.meta.strats.XMLValueHandler")
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
This allows a user to indicate that OpenJPA should use JAXB
classmetadata to perform the to/from database value retrieval
and storage. In addition, using this strategy indicates there
is an XMLType used to store the value in the database.
Instead, we've seen customers attempt to managing their own
XML string, mapped to a string field, and expect the code
changes of this fix to apply. While an appliation may have an
XMLType specified in the column definition, OpenJPA cannot
count on this data to detect whether the column is really an
XML column in the database (the table could have been created
manually &#130; &#160;with &#130; &#160;separate &#130; &#160;DDL &#130; &#160;instead &#130; &#160;of &#130; &#160;using &#130;
tool).  In the case where the user is doing their own
String mapping rather than using the XMLValueHandler, there
are some additional settings a user may need to set/enable in
order to resolve the issue addressed in this fix. The necessary
settings/actions are as follows:

First, it may be necessary to annotate an XML field with
@Lob, &#130; &#160;as &#130; &#160;follows: &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
@Lob &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
@Column(name="CONTENTS_XML", &#130; &#160;columnDefinition &#130; &#160;="XMLCOLUMN
e") &#130; &#160;
private &#130; &#160;String &#130; &#160;contentsXml; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
Second, in &#130; &#160;addition &#130; &#160;to &#130; &#160;annotating the XML field with @L
user may also need to set this dictionary property:

 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
maxEmbeddedClobSize=-1 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
Therefore, &#130; &#160;the &#130; &#160;final &#130; &#160;DBDictionary &#130; &#160;property &#130; &#160;would
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
<property &#130; &#160;name="openjpa.jdbc.DBDictionary" &#130; &#160;value="oracle(s
sSetClob=true,maxEmbeddedClobSize=-1)"/> &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
Finally, &#130; &#160;a user may need to &#130; &#160;use &#130; &#160;the &#130; &#160;native schema
factory &#130; &#160;to &#130; &#160;pick &#130; &#160;up &#130; &#160;the &#130; &#160;XMLType &#130; &#160;from &#130; &#160;the &#130; &#160;
that &#130; &#160;property &#130; &#160;is &#130; &#160;as &#130; &#160;follows:
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;
<property &#130; &#160;name="openjpa.jdbc.SchemaFactory" &#130; &#160;value="native"
 &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160; &#130; &#160;

By &#130; &#160;enabling &#130; &#160;OpenJPA's native schema factory, the database
column type can be detected as XMLType.



The fix for this APAR is currently targeted for
inclusion in Service Levels (Fix Packs) 7.0.0.21 and 8.0.0.2 of
WebSphere Application Server versions 7.0.0 and 8.0.0.

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
PM41128
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2011-06-08
Closed date
2011-09-30
Last modified date
2011-09-30

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

PM43675

Fix information

Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800

Applicable component levels

R700 PSY
UP
R800 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":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
27 October 2021

Tips

PM41128: JIRA OPENJPA-1691 DEFECT BACKPORTED TO V7 OPENJPA 1.2.X

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

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

Fixed component ID

Applicable component levels

R700 PSY

R800 PSY

Document Information

Share your feedback

Need support?