Informix: Error while trying to set up start or end key for index read

[Ulf Akerberg]

Hi all

Im moving an application from weblogic 6.1 to 8.1, we're using informix as our databasemanager and are using informix's XA driver. However im running into the following error:

SQL State: IX000, Exception: java.sql.SQLException: [Internal] Error while trying to set up start or end key for index read [fmstopset_release],
SQL ErrorCode: -9847, Error Message: [Internal] Error while trying to set up start or end key for index read [fmstopset_release], RSAM ErrorCode: -101

..while accessing a table.
The same code runs fine twice, but the third and following times it fails with the above error code. I've tried setting the various XA flags available in the weblogic console but with no success so far.

Anyone have any input to this problem? Ive not seen many postings about this error out in the cyberspace and the fews ive seen never gets any response...so i just have to hope anyone in here know anything about it.

Best regards
JM

[Slava Imeshev]

"Ulf Akerberg" <noad...@noaddress.given> wrote in message news:17441137.1094797411484.JavaMail.root@jserv5...

Can you post full stack trace?

Regards,

Slava Imeshev

[Ulf Akerberg]

Hello

I managed to work around my problem by setting the "statement cache size" in the jdbc connection pool to 0. At least that seems to be a work around, im not fully happy with it.
I attach the stack trace from the exception, perhaps it will give someone an idea.
Btw, we're using sun.jdbc.rowset.ExtendedCachedRowSet to populate the resultset to a "disconnected resultset" which the application works with instead of the resultset. Any statements and resultsets that are created are closed before returning the ExtendedCachedRowSet to the application.

2004-09-10 15:45:05,603 ERROR [ExecuteThread: '14' for queue: 'weblogic.kernel.Default'] - SQLException: Generic SQL failed:
SELECT d.*,dt.dokument_typ FROM dokument d, OUTER dokument_typ dt WHERE d.dok_typ_id = dt.dok_typ_id AND d.dokument_id = ? ( 0:894),

SQL State: IX000, Exception: java.sql.SQLException: [Internal] Error while trying to set up start or end key for index read [fmstopset_release],
SQL ErrorCode: -9847, Error Message: [Internal] Error while trying to set up start or end key for index read [fmstopset_release], RSAM ErrorCode: -101
java.sql.SQLException: [Internal] Error while trying to set up start or end key for index read [fmstopset_release]

at com.informix.jdbc.IfxSqli.addException(IfxSqli.java:3105)
at com.informix.jdbc.IfxSqli.receiveError(IfxSqli.java:3419)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2282)
at com.informix.jdbcx.IfxXASqli.receiveMessage(IfxXASqli.java:119)
at com.informix.jdbc.IfxSqli.sendStatementQuery(IfxSqli.java:1464)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1403)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1333)
at com.informix.jdbc.IfxResultSet.executeQuery(IfxResultSet.java:223)
at com.informix.jdbc.IfxStatement.executeQueryImpl(IfxStatement.java:843)
at com.informix.jdbc.IfxPreparedStatement.executeQuery(IfxPreparedStatement.java:244)
at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)
at infrastructure.dao.AbstractDAO.genericSqlRead(AbstractDAO.java:166)
at se.migrationsverket.dhs.domain.dao.DokumentDAO.findByDokId(DokumentDAO.java:64)
at se.migrationsverket.dhs.domain.dao.DokumentDAO.findByDokId(DokumentDAO.java:43)
at se.migrationsverket.dhs.generator.impl.pipeline.LoadDocumentPipeline.buildMultiDocument(LoadDocumentPipeline.java:99)
at se.migrationsverket.dhs.generator.impl.pipeline.LoadDocumentPipeline.process(LoadDocumentPipeline.java:53)
at se.migrationsverket.dhs.generator.impl.DHSDocumentGenerator.loadDocument(DHSDocumentGenerator.java:63)
at se.migrationsverket.dhs.generator.DocumentGeneratorInternalHelper.loadDocument(DocumentGeneratorInternalHelper.java:129)
at se.migrationsverket.dhs.services.document.internal.InternalDocumentManagerBean.loadDocument(InternalDocumentManagerBean.java:185)
at se.migrationsverket.dhs.services.document.internal.InternalDocumentManager_6sz7e8_EOImpl.loadDocument(InternalDocumentManager_6sz7e8_EOImpl.java:532)
at se.migrationsverket.dhs.action.documentgenerator.GeneratorAction.load(GeneratorAction.java:147)
at se.migrationsverket.dhs.action.documentgenerator.GeneratorAction.perform(GeneratorAction.java:49)
at se.migrationsverket.dhs.servlet.AbstractController.doPost(AbstractController.java:84)
at se.migrationsverket.dhs.servlet.AbstractController.doGet(AbstractController.java:54)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

Regards
JM

[Joe Weinstein]

Ulf Akerberg wrote:
> Hello
>
> I managed to work around my problem by setting the "statement cache size" in the jdbc connection pool to 0. At least that seems to be a work around, im not fully happy with it.
> I attach the stack trace from the exception, perhaps it will give someone an idea.
> Btw, we're using sun.jdbc.rowset.ExtendedCachedRowSet to populate the resultset to a "disconnected resultset" which the application works with instead of the resultset. Any statements and resultsets that are created are closed before returning the ExtendedCachedRowSet to the application.
>

If the application works when statement caching is turned off, then it implies a bug in the
informix driver to do with re-using a prepared statement. Is the PreparedStatement used
the same way each time? (the one at AbstractDAO.java:166) What I mean to ask is, If/when
this statement is created with a given SQL string, are the parameters for that SQL always
set the same way?
thanks,
Joe