To simplify things, in a nutshell, the new oracle 11g driver has this logic:
if (pos == 518630185893888L)
{
if (lobStreamPosStandardCompliant)
{
throw
DatabaseError.createSqlException(getConnectionDuringExceptionHandling(), 68);
}
...
}
and the old oracle 10g driver looks like this:
if (pos == 518630185893888L)
{
return new OracleBlobOutputStream(blob, chunkSize);
}
So I looked at the lobStreamPosStandardCompliant i-var in the oracle driver and
I noticed that it is being initialized from the
oracle.jdbc.LobStreamPosStandardCompliant property which defaults to true. So
if I set the property to false in my Properties file like this:
oracle.jdbc.LobStreamPosStandardCompliant=false
then the 11g driver works fine.
But it makes me nervous setting this property. Anyways, I'm just putting this
out here to see if anybody has an idea of what this is.
On May 11, 2010, at 3:35 PM, Ricardo J. Parada wrote:
> On May 11, 2010, at 1:34 PM, Chuck Hill wrote:
>
>>
>> On May 11, 2010, at 8:57 AM, Ricardo J. Parada wrote:
>>
>>>
>>> We upgraded ORACLE to 11g and so I switched to the 11g driver. But now we
>>> started getting these exceptions:
>>>
>>> [2010-05-11 07:31:24,579] ERROR
>>> com.webobjects.eoaccess.EOGeneralAdaptorException: Invalid argument(s) in
>>> call
>>> at
>>> com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseContextInformationAdded(EODatabaseContext.java:4504)
>>> at
>>> com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseContext.java:6216)
>>> at
>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:376)
>>> at
>>> com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192)
>>> at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1085)
>>> at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1007)
>>> ...
>>>
>>> I suspect it is related to BLOB fields because it happens right after EOF
>>> issues SQL to insert into a table with a BLOB field. The SQL looks
>>> something like this:
>>>
>>> INSERT INTO MIME_CONTENT(DEFAULT_DOWNLOAD_FILE_NAME, MIME_TYPE,
>>> CREATION_DATE, MIME_CONTENT, MIME_CONTENT_ID) VALUES (?, ?, ?,
>>> EMPTY_BLOB(), ?)" withBindings:
>>> 1:"BasicAdHocReport.csv"(defaultDownloadFileName),
>>> 2:"text/comma-separated-values"(mimeType), 3:2010-05-11
>>> 11:17:00(creationDate), 4:496737(mimeContentID)
>>>
>>> SELECT t0.MIME_CONTENT FROM MIME_CONTENT t0 WHERE t0.MIME_CONTENT_ID = ?
>>> FOR UPDATE" withBindings: 1:496737(mimeContentID)
>>
>>
>> SELECT ... FOR UPDATE usually means that WO has gotten totally confused. It
>> should probably be doing something like
>> UPDATE MIME_CONTENT SET MIME_CONTENT = .... where MIME_CONTENT_ID = 496737
>>
>> See http://www.google.ca/search?q=SELECT+%22FOR+UPDATE%22+webobjects&;
>>
>> Often this indicates a difference between your prototypes and the name /
>> case of the data type that the JDBC driver is returning.
>
> The field is defined as follows in the eomodel:
>
> {
> columnName = "MIME_CONTENT";
> externalType = BLOB;
> name = mimeContent;
> valueClassName = NSData;
> },
>
> It's not using a prototype but I checked ERPrototypes' definition of the blob
> prototype for ORACLE and it seems that this is setup right.
>
> It has always seemed weird to me that I don't see an UPDATE MIME_CONTENT SET
> MIME_CONTENT = ... WHERE MIME_content_id = 496737 like you mentioned.
> However, the SQL looks the identical with the old driver except that no
> exception is thrown and the field in the database ends up with the blob in
> there.
>
> I noticed that the exception class is EOGeneralAdaptorException and it has a
> userInfo dictionary. So I peeked at that and I see more info that shows a
> stack trace with line numbers inside the oracle driver. It shows the
> exception happening at line #4388 in the newOutputStream(BLOB blob, int
> chunkSize, long pos, boolean zeroInvalid method. And in JD-GUI it seems that
> for that to happen pos is a really large number and zeroInvalid &
> lobStreamPosStandardCompliant return true. ( I didn't know a bitwise and
> with a boolean was a valid expression in java... :-/)
>
> public OutputStream newOutputStream(BLOB blob, int chunkSize, long pos,
> boolean zeroInvalid)
> throws java.sql.SQLException
> {
>
> ...
>
> if (pos == 518630185893888L)
> {
> if ((zeroInvalid & this.lobStreamPosStandardCompliant))
> {
> ...
>
> java.sql.SQLException __ex__ =
> DatabaseError.createSqlException(getConnectionDuringExceptionHandling(), 68);
> 4388: __ex__.fillInStackTrace();
> throw __ex__;
> }
>
> …
>
> }
>
>
>>
>>
>> Chuck
>>
>>
>>>
>>>
>>> Switching to the old driver makes the exception go away. Any wild guess if
>>> this is an EOF problem or a driver problem?
>>>
>>> For reference, the version of the oracle jdbc driver is 11.2.0.1.0.
>>>
>>> Thanks for any help,
>>> Ricardo
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>
>>> This email sent to [email protected]
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall
>> knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
