When changing to use a connection pool set up with oracles thin driver we get an
ORA 0600 general exception instead.
Excerpt from config file:
<JMSServer Name="EBP JMS Server" Store="EBP JMS JDBC Store" Targets=""><JMSQueue
JNDIName="testQueue" Name="testQueue"/>
</JMSServer>
<JMSJDBCStore ConnectionPool="EBPDEV"
Name="EBP JMS JDBC Store" PrefixName="EBP"/>
<JDBCConnectionPool DriverName="weblogic.jdbc.oci.Driver"
MaxCapacity="10" Name="EBPDEV"
Properties="user=ebp;password=ebp;server=EBPDEV"
Targets="ebpServer" URL="jdbc:weblogic:oracle"/>
Anyone have a solution to the problem?
/ Andreas
Meanwhile you might want to give the 8.1.7 client a shot.
Varun
PreparedStatementCacheSize="0"
We have seen some new problems with Oracle 9.0.1 regarding reusing prepared
statements that have null values one time, then a long integer value the
next time.
This will turn off the statement cache so you can't run into this problem.
Thanks.
"Andreas " <andrea...@hi3gaccess.se> wrote in message
news:3cd0f201$1...@newsgroups2.bea.com...
/ Andreas
/ Andreas
<May 3, 2002 10:36:04 AM CEST> <Alert> <JMS> <JMSServer "EBP JMS Server", store failed
to open, java.io.IOException: JMS JDBC store, connection pool = <EBPDEV>, prefix
= <EBP>: change state
java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into a LONG
column
at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:240)
at weblogic.jdbc.oci.Statement.executeUpdate(Statement.java:990)
at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
at weblogic.jms.store.JDBCIOStream.changeState(JDBCIOStream.java:417)
at weblogic.jms.store.JDBCIOStream.setVersion(JDBCIOStream.java:1592)
at weblogic.jms.store.JDBCIOStream.open(JDBCIOStream.java:290)
at weblogic.jms.store.JMSStore.open(JMSStore.java:107)
at weblogic.jms.backend.BEStore.open(BEStore.java:180)
at weblogic.jms.backend.BackEnd.initialize(BackEnd.java:390)
at weblogic.jms.JMSService.createBackEnd(JMSService.java:907)
at weblogic.jms.JMSService.addJMSServer(JMSService.java:1274)
at weblogic.jms.JMSService.addDeployment(JMSService.java:1170)
at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:329)
at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:144)
at java.lang.reflect.Method.invoke(Native Method)
at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:359)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:491)
at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:361)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
at $Proxy17.addDeployment(Unknown Source)
at weblogic.management.internal.DynamicMBeanImpl.updateDeployments(DynamicMBeanImpl.java:1516)
at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:895)
at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:847)
at weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:295)
at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:322)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:204)
at $Proxy11.setTargets(Unknown Source)
at weblogic.management.console.webapp._domain.__jmsserver$TargetAttribute.doSet(__jmsserver.java:92)
at weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:135)
at weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:171)
at weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
This is a new one. Other than trying different drivers at different versions (which you have done), I have
no suggestion beyond dropping the tables before trying each new driver (which you might not have done).
A hack solution might be to modify the .ddl that creates the tables to change the column types from int to long,
and run the ddl yourself (JMS doc appendix tells how to extract the .ddl file from the weblogic.jar and run it).
Meanwhile, I suggest using a file store instead of a JDBC store for the duration, and contacting customer support.
Tom
Try setting the NLS_LANG(same as the db) value in the startup script.
Andreas wrote:
--
Rajesh Mirchandani
Developer Relations Engineer
BEA Support