Re: OJB 1.0.4, Oracle 10g and LONGVARCHAR column issue

Hi Vasily,

could you please open an issue on OJB-JIRA
http://issues.apache.org/jira/browse/OJB
and add a detailed description about how to reproduce the issue (then 
I'm able to write a test case).

regards,
Armin

Vasily Ivanov wrote:
> Hello,
> 
> I'm using Oracle 10.2.0.4.0 thin Jdbc driver, Oracle 10g db, Ojb
> 1.0.4, Tomcat 4, c3p0 connection pooling, Spring/Spring Modules.
> 
> I'm experiencing a problem materializing an object with LONGVARCHAR
> field (LONG datatype in Oracle).
> 
> Caused by: java.sql.SQLException: Stream has already been closed
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208)
> 	at oracle.jdbc.driver.LongAccessor.getBytes(LongAccessor.java:151)
> 	at oracle.jdbc.driver.LongAccessor.getString(LongAccessor.java:193)
> 	at oracle.jdbc.driver.T4CLongAccessor.getString(T4CLongAccessor.java:426)
> 	at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:403)
> 	at com.mchange.v2.c3p0.impl.NewProxyResultSet.getString(NewProxyResultSet.java:3316)
> 	at org.apache.ojb.broker.metadata.JdbcTypesHelper$T_LongVarChar.readValueFromResultSet(JdbcTypesHelper.java:449)
> 	at org.apache.ojb.broker.metadata.JdbcTypesHelper$BaseType.getObjectFromColumn(JdbcTypesHelper.java:331)
> 	at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readValuesFrom(RowReaderDefaultImpl.java:246)
> 	at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObjectArrayFrom(RowReaderDefaultImpl.java:208)
> 	at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:457)
> 	at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:278)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:131)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:263)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollection(QueryReferenceBroker.java:764)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:722)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollections(QueryReferenceBroker.java:973)
> 	at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:940)
> 	at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:488)
> 	at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:278)
> 	at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(PersistenceBrokerImpl.java:1770)
> 	at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:352)
> 	at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:352)
> 	at org.springmodules.orm.ojb.PersistenceBrokerTemplate$2.doInPersistenceBroker(PersistenceBrokerTemplate.java:187)
> 	at org.springmodules.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:141)
> 
> Oracle documentation reads that:
> "If you try to access the data for the none-stream column before
> reading the data from the streaming column the JDBC driver discards
> the streaming data automatically. You cannot access that data any
> more. If you try to get a stream for the LONG column the driver raises
> a "Stream Closed" error."
> 
> Even if LONGVARCHAR field is specified first in the list of
> field-descriptors OJB ignores that and tries to get none-stream PK
> fields first (see method RsIterator#getObjectFromResultSet() which
> calls RowReaderDefaultImpl#readPkValuesFrom()) and only than it tries
> to get LONGVARCHAR column and fails because stream has already been
> invalidated by Oracle driver at that point.
> 
> I have no idea how to get around this problem. The only solution I can
> think about is providing my own implementation of RowReaderDefaultImpl
> for that particular class.
> 
> Surprisingly enough it works fine if I change connection pooling from
> c3p0 to commons dbcp... Maybe DBCP silently swallows "Stream has
> already been closed" SQLException? I haven't looked into there yet.
> 
> Thank you,
> Vasily
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
>