WL6.0sp2: ORA-01475 Must reparse cursor to change bind variable excpetion
Krishna Kumar
Hi,
This exception is showing up in WL6.0 sp2 but in a really strange place. I am
using BMP EJBs and the SQL code in question
prepares a statement, sets arguments, executes it exactly once and then closes
it. I have this pattern in a number of different places in my application. The
must reparse exception keeps showing up sporadically. From what I have been able
to determine it does not happen when the EJB method is called standalone, but
it seems to happen when the method is called as part of a longer client initiated
transaction ( although I cannot confirm 100% that this is the dividing line).
In any case, for the type of usgae in question it seems like this problem should
never occur in the first place.
I am migrating from WL4.51 directly to WL6.0 and this code has been working without
any issues for over a year... I have attached a sample function below where the
exception is thrown...
Any help will be greatly appreciated.
krishna
public void updateCheckoutRecord(Integer entityID, Integer instanceId, Integer
versionId, AbstractEntityState state) throws PersistenceException
{
if(!m_classTable.isPrincipal()) return;
if((state.isCheckedOut()) && (state.getCheckoutOwner()==null)) throw new PersistenceException("Checkout
object with no owner " + entityID + ":" + instanceId);
int rows = -1;
try {
Connection conn = m_persistenceManager.getConnection(this);
PreparedStatement updateCheckoutRecord=conn.prepareStatement(m_updateCheckoutRecordStatement);
try{
updateCheckoutRecord.setObject(1, (state.isCheckedOut()? ONE : ZERO));
updateCheckoutRecord.setObject(2,state.getCheckoutOwner());
//CheckoutTime
updateCheckoutRecord.setObject(3, (state.getCheckoutTime()==null ? null :
new Timestamp(state.getCheckoutTime().getTime())));
updateCheckoutRecord.setObject(4, state.getLastModified()==null ? null : new
Timestamp(state.getLastModified().getTime()));
updateCheckoutRecord.setObject(5,(state.isPrivate()? ONE : ZERO));
updateCheckoutRecord.setObject(6,(state.isInitialized()? ONE: ZERO));
updateCheckoutRecord.setObject(7,state.getSecurityDescriptor());
updateCheckoutRecord.setObject(8,state.getAclName());
updateCheckoutRecord.setObject(9,instanceId);
rows = updateCheckoutRecord.executeUpdate();
}finally{
updateCheckoutRecord.close();
conn.close();
}
}catch(SQLException ex) {
Framework.trace(TRACE_TAG,Thread.currentThread().getName() + "Exception
on update checkout record " + entityID + "," + instanceId);
ex.printStackTrace();
if(DBAbstraction.isSerializationError(ex)) throw new TransactionSerializationException(ex.getMessage());
throw new PersistenceException(ex.getMessage());
} catch(TransactionSerializationException tx){
Framework.trace(TRACE_TAG,Thread.currentThread().getName() + "Serialization
Exception on create update record. CR= " + entityID + "," + instanceId);
tx.printStackTrace();
throw tx;
}
if(rows != 1) throw new PersistenceException("Could not update checkout record.
No rows for instance " + instanceId + " were updated.");
}
Joseph Weinstein
This likely has to do with the recent performance enhancement to pools,
wherein we cache PreparedStatements. Is there any possibility in your code,
that you create a PreparedStatement with identical SQL, but in different
places in the code, you call different setXXX() calls to define the parameter
values? Such as setInt(1) in one method, but setLong(1) in another, with the
same SQL?
thanks,
Joe
--
PS: Folks: BEA WebLogic is expanding rapidly, with both entry and advanced positions
for people who want to work with Java, XML, SOAP and E-Commerce infrastructure products.
We have jobs at Nashua NH, Liberty Corner NJ, San Francisco and San Jose CA.
Send resumes to j...@bea.com
David W. Archer
>Hi Krisha.
>
>This likely has to do with the recent performance enhancement to pools,
>wherein we cache PreparedStatements. Is there any possibility in your code,
>that you create a PreparedStatement with identical SQL, but in different
>places in the code, you call different setXXX() calls to define the parameter
>values? Such as setInt(1) in one method, but setLong(1) in another, with the
>same SQL?
>thanks,
>Joe
We, too, are experiencing this problem with WLS 6.0 SP2, but we are using CMP,
so we have no visibility into the generated code to know which setXXX() calls
are being made. Did the performance enhancement cause a known problem
with CMP?
Thanks,
Dave
P.S. Here is my stack trace:
<Jul 9, 2001 6:33:03 PM EDT> <Info> <EJB> <EJB Exception in method: ejbCreate: javax.ejb.EJBException - with nested exception:
[java.sql.SQLException: ORA-01475: must reparse cursor to change bind variable datatype]
java.sql.SQLException: ORA-01475: must reparse cursor to change bind variable datatype
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:238)
at weblogic.jdbcbase.oci.Statement.executeUpdate(Statement.java:869)
at weblogic.jdbcbase.jts.Statement.executeUpdate(Statement.java:345)
at com.cclinic.person.PersonBean_WebLogic_CMP_RDBMS.__WL_create(PersonBean_WebLogic_CMP_RDBMS.java:1013)
at com.cclinic.person.PersonBean_WebLogic_CMP_RDBMS.ejbCreate(PersonBean_WebLogic_CMP_RDBMS.java:932)
at java.lang.reflect.Method.invoke(Native Method)
at weblogic.ejb20.manager.DBManager.create(DBManager.java:410)
at weblogic.ejb20.internal.EntityEJBHome.create(EntityEJBHome.java:353)
at com.cclinic.person.PersonBeanHomeImpl.create(PersonBeanHomeImpl.java:92)
at com.cclinic.person.PersonServiceBean.updatePerson(PersonServiceBean.java:845)
at com.cclinic.person.PersonServiceBeanImpl.updatePerson(PersonServiceBeanImpl.java:170)
at com.cclinic.person.PersonServiceBeanEOImpl.updatePerson(PersonServiceBeanEOImpl.java:144)
at com.cclinic.patient.PatientServiceBean.updatePatient(PatientServiceBean.java:215)
at com.cclinic.patient.PatientServiceBeanImpl.updatePatient(PatientServiceBeanImpl.java:150)
at com.cclinic.patient.PatientServiceBeanEOImpl.updatePatient(PatientServiceBeanEOImpl.java:105)
at com.cclinic.patient.PatientServiceBeanEOImpl_WLSkel.invoke(PatientServiceBeanEOImpl_WLSkel.java:218)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:373)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:128)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestHandler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Joseph Weinstein
"David W. Archer" wrote:
>
> On Mon, 25 Jun 2001 15:06:38 -0700, Joseph Weinstein <j...@bea.com> wrote:
>
> >Hi Krisha.
> >
> >This likely has to do with the recent performance enhancement to pools,
> >wherein we cache PreparedStatements. Is there any possibility in your code,
> >that you create a PreparedStatement with identical SQL, but in different
> >places in the code, you call different setXXX() calls to define the parameter
> >values? Such as setInt(1) in one method, but setLong(1) in another, with the
> >same SQL?
> >thanks,
> >Joe
>
> We, too, are experiencing this problem with WLS 6.0 SP2, but we are using CMP,
> so we have no visibility into the generated code to know which setXXX() calls
> are being made. Did the performance enhancement cause a known problem
> with CMP?
No. You should definitely open an offical support case for this.
Joe
--
David W. Archer
We eventually solved our problem. For posterity, here's what happened:
We had an entity EJB with a Boolean called female. It was mapped to a CHAR(1)
on our Oracle database. According to our documentation, that should work fine,
but we got the "must reparse cursor" error whenever the Boolean was null.
The developer changed the female field in the bean to a String and the field in
database to a VARCHAR2(5). Since we use the value object pattern, the developer
left the female field in the value object as a Boolean and mapped the it to either
null or valueObject.female.toString() in the bean. That way, most of our code
was able to keep using the field as a Boolean. Only the value object and entity
beans needed code changes.
Personally, I think Weblogic has a bug that caused our original implementation
to fail. Also, there may be a different database field type that would fix the
problem without any code changes at all (perhaps simply VARCHAR2(1)?).
Either way, this solution got us around the prolem.
Dave