[
https://issues.apache.org/jira/browse/OPENJPA-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775126#action_12775126
]
Jeremy Bauer commented on OPENJPA-1248:
---------------------------------------
These tests are two of the few remaining failures in the o-j-p project when
running on Oracle. (Version XE/10 using the 11.2.0.1 driver) I found a few
issues and came up with a couple of options for fixing them.
First, when inserting a LOB OpenJPA currently inserts a null value into the LOB
column. When this value is retrieved from the result set (res.getBlob) it is
null - and not an updatable blob. This is currently causing an NPE. If an
Oracle empty_[b,c]lob() is inserted, the rs will return an updatable lob.
However, this changes behavior a bit since null != empty and some of the test
assertions that assert a persistent stream attribute is NULL will fail.
Another option is to continue to insert a NULL value then when doing the
update, create a temporary lob (using Oracle APIs) and do the update. I've
found this to be troublesome - especially when connection pooling is used -
since the Oracle APIs assert that the connection they are provided is an Oracle
connection. I put together a DBCP/JDBC 4 reflection-based solution but it is
cumbersome. Worse yet, DBCP requires a special property be set to get access
to the underlying connection.
I think the cleanest solution would be to use empty_lob() and change the
behavior of the tests to expect an empty stream when using Oracle. A hybrid
solution would handle cases where an existing value is null... but this might
be overkill.
The second issue (after correcting the first) was that the test was failing
with an exception indicating that the connection is closed when reading from
the updated BLOB. This issue is related to OpenJPA connection management and
the need for Oracle streaming LOBs to maintain an open connection. The issue
was corrected on Oracle by setting the property
openjpa.ConnectionRetainMode=transaction, indicating that em should use the
same connection for the duration of the transaction. Some applications may
need to use mode "always", depending on transactional patterns and when the LOB
is accessed - but that can result in an inefficient use of connections in a
pooled environment. This needs to be documented in the OpenJPA manual as part
of this JIRA. Unfortunately, this did not correct similar test failures on SQL
Server. SQL Server will require additional investigation.
Unless someone(s) is/are in strong disagreement, I'll be committing code to
trunk which fixes the Oracle failures by using empty_[c,b]lob() instead of
inserting null. The tests will be modified to assert that the stream is empty
(instead of null) when running with Oracle. I'll also attach a patch to
OPENJPA-1249 (since the patch is Oracle specific) that uses native Oracle
methods to handle null LOBs as an alternative solution. Finally, the Oracle
section of the manual will be updated to include the ConnectionRetainMode
requirement for streaming LOBs.
> LOB streaming does not work as expected
> ---------------------------------------
>
> Key: OPENJPA-1248
> URL: https://issues.apache.org/jira/browse/OPENJPA-1248
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 1.1.0, 1.2.0, 1.2.1, 1.3.0, 2.0.0
> Environment: Oracle, MySQL, PostgreSQL, SQL Server
> Reporter: Milosz Tylenda
> Attachments: failures.txt, TestReaderLob_oracle.log
>
>
> TestReaderLob does not pass with any of the databases indicated in the test
> case: Oracle, MySQL, PostgreSQL, SQL Server. TestInputStreamLob passes only
> with MySQL and PostgreSQL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
