JDBC 4.0 Bug

In JDBC 4.0 specification, the @Select annotation is used to obtain a result set with a SQL query. According to JDBC 4.0 specification, the result set is read-only by defaullt. If the result set is required to be modified, annotation element readOnly is to be set to false.
The examples to modify a result set, and delete from a result set in JDBC 4.0 specification do not set readOnly annotation element to false as required.
http://www.jcp.org/en/jsr/detail?id=221

Well, the JDBC 4.0 specification is not yet final, as an implementor we cannot comment or fix a potential bug until the spec is final. Having said that I'll forward this to our rep at the JDBC JSR Expert Group.
Kuassi - http://db360.blogspot.com/

Similar Messages

JDBC Binding Component Bug

We need to use the JDBC binding component but run into this error when trying it against the Derby sample database:
Gettin bean for {http://j2ee.netbeans.org/wsdl/TestJDBC}serviceport
Adding reply listener for messsage exchange:190736427284860-12041-134354767608280052
Received in-only message 190736427284860-12041-134354767608280052.
Processing one-way inbound messages...
Executing sql . update PURCHASE_ORDER set FLAG = 1 whereORDER_NUM=10398001
Error occured while executing sql.update PURCHASE_ORDER set FLAG = 1 whereORDER_NUM=10398001
Finished processing message with exchange id of [190736427284860-12041-134354767608280052]. Removing the exchange id...
Finished processing outbound messages.
BPCOR-6151:The process instance has been terminated because a fault was not handled; Fault Name is {http://docs.oasis-open.org/wsbpel/2.0/process/executable}selectionFailure; Fault Data is null
com.sun.jbi.engine.bpel.core.bpel.exception.StandardException: I18N: BPCOR-3023: Selection Failure occurred in BPEL({http://enterprise.netbeans.org/bpel/testJDBC/TestJDBC}TestJDBC) at line 22!
Looks like someone forgot the space after "where" which causes the SQL statement to break. Is there a fix?
Also when using the polling type, the log shows select * rather than using the select statement with column values defined in the WSDL.
Received in-only message.
Executing sql . select * from PURCHASE_ORDER
normalized message
Finished executing the SQL successfully.
Accepted the message in JDBC Binding. 190736427284860-12041-134354767608280052
Accepted message with exchange ID 190736427284860-12041-134354767608280052 in JDBC outbound message processor.

This is the error caused by the null string database column value retrieved during the polling process:
IN_ONLY select statement processed
normalized message
I18N: BPJBI-3002: Pattern for exchange Id 202752488871337-35996-134357795744840255 is http://www.w3.org/2004/08/wsdl/in-only
ERROR: ''
ERROR: ''
ERROR: ''
ERROR: ''
BPJBI-6010:Failed to process In Only Message M Ex 202752488871337-35996-134357795744840255
java.lang.RuntimeException: BPCOR-6096:Error occurred while converting the node to a string.
at com.sun.jbi.engine.bpel.core.bpel.util.DOMHelper.createXmlString(DOMHelper.java:137)
at com.sun.jbi.engine.bpel.core.bpel.util.DOMHelper.createXmlString(DOMHelper.java:103)
at com.sun.jbi.engine.bpel.core.bpel.engine.impl.JBIMessageImpl.toString(JBIMessageImpl.java:345)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuffer.append(StringBuffer.java:219)
at com.sun.jbi.crl.util.LocalizationSupport.salvage(LocalizationSupport.java:115)
at com.sun.jbi.crl.util.LocalizationSupport.format(LocalizationSupport.java:126)
at com.sun.jbi.crl.util.LocalizationSupport.t(LocalizationSupport.java:181)
at com.sun.jbi.engine.bpel.util.I18n.loc(I18n.java:50)
at com.sun.jbi.engine.bpel.BPELSEInOutThread.processRequest(BPELSEInOutThread.java:612)
at com.sun.jbi.engine.bpel.BPELSEInOutThread.processMsgEx(BPELSEInOutThread.java:308)
at com.sun.jbi.engine.bpel.BPELSEInOutThread.run(BPELSEInOutThread.java:194)
Caused by: javax.xml.transform.TransformerException: java.lang.NullPointerException
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:717)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
at com.sun.jbi.engine.bpel.core.bpel.util.DOMHelper.createXmlString(DOMHelper.java:124)
... 11 more

Oracle JDBC 10g - InitialLimit bug ?

'Lo everybody !
I'm testing OracleConnectionCacheManager and its InitialLimit parameter.
DOCUMENTATION:
http://download-west.oracle.com/docs/cd/B12037_01/java.101/b10979/conncache.htm
"InitialLimit:
Sets how many connections are created in the cache when it is created or reinitialized.
When this property is set to an integer value greater than 0,
creating or reinitializing the cache automatically creates the specified number of connections,
filling the cache in advance of need."
TESTING:
Setting InitialLimit=5 and MaxLimit=10: I can only get 5 connections.
Setting InitialLimit=10 and MaxLimit=10: I cannot get any connection.
Setting InitialLimit=0 and MaxLimit=10: I can get up to 10 connections.
Well, it seems that the InitialLimit connections are created BUT cannot be used at all !
Anybody can confirm this ?
Thanx.
Jean.

Hi,
Yes, I have the same experience.
I read the documentation many times and knew what their meanings , but got your result. Any suggestion ?

Oracle8 apache jdbc connect problem

I have an instance of oracle 8 on my workstation I've got the Apachewebserver running executing code in the servlets directory fine. The connect string is :-
jdbc:oracle:thin:@localhost:1521:yemi", "yemi", "yemi"
It works perfectly. There are 2 production servers also running oracle 8 . I've got the webserver running and used the same code ( changing sid, username and password) in the servlets directory. I always get now ORA-01017 Invalid username/password . I've checked the username and password by running sqlplus and copying and pasting the username/password from the java connect string and it connects perfectly.
What on earth am I doing wrong ?

Just in cast anyone is interested , we found the solution today. The username in question had a "@" in it ie bla@something. this worked fine in sqlplus conect but didnt using jdbc. A bug has been now recorded against this feature.

Rollback functionality has bugs??

Hi,
Can i vertify that whether rollback in JDBC has any bugs or not?
My sources are like this :
try
Connection con = getConnection();
Statement stmt = con.createStatement();
String sql = " ..........." +
stmt.executeUpdate(sql);
String sql1 = " ..........." +
stmt.executeUpdate(sql1);
catch(SQLExeception sqle)
System.out.println("Error: + sql.getMessage();
if(con != null)
con.rollback();
I used one statement object to update two tables.If the second sql statement has errors occcur,the first sql values can not be rollback.
Can anyone check this code and give some suggestion?
I would like to rollback all values if any sql exception occurs.
Thanks
regards,
marcalena

Hi,
Ok this is the original source code:
Can you check that and let me know thanks.
try {
Class.forName("com.mysql.jdbc.Driver");
con = getConnection();
con.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
con.setAutoCommit(false);
Statement stmt = con.createStatement();
String info1 = "....................................................." +
stmt.executeUpdate(info1);
if(cpl.getTable().getCellEditor() != null)
cpl.getTable().getCellEditor().stopCellEditing();
for(int i=0 ; i<table.getRowCount() ; i++) {
String name = table.getValueAt(i,1).toString();
int d= Integer.parseInt(table.getValueAt(i,2).toString());
double q= Double.parseDouble(table.getValueAt(i,3).toString());
String UOM = table.getValueAt(i,4).toString();
String medicineID = getID(name);
String info2= "................................................ " +
stmt.executeUpdate(info2);
String info3= "........................................" +
stmt.execute(info3);
String info4= "......................................" +
stmt.executeUpdate(info4);
SQLWarning warning = stmt.getWarnings();
if(warning != null) {
JOptionPane.showMessageDialog(null,"Error in inserting","System Manager",JOptionPane.ERROR_MESSAGE);
con.rollback();
else {
stmt.close();
con.commit();
con.close();
setVisible(false);
catch(SQLException ext) {
JOptionPane.showMessageDialog(null,"SQL Exception:","ERROR",JOptionPane.ERROR_MESSAGE);
while (ext != null) {
JOptionPane.showMessageDialog(null,"SQL State:" + ext.getSQLState() + "\nMessage:" + ext.getMessage() + "\nVendor:" + ext.getErrorCode(),"ERROR",JOptionPane.ERROR_MESSAGE);
ext = ext.getNextException();
if(con != null) {
try {
JOptionPane.showMessageDialog(null,"Transaction is being rollback","System Manager",JOptionPane.INFORMATION_MESSAGE);
con.rollback();
catch(SQLException excep) {
JOptionPane.showMessageDialog(null,"SQL Exception: " + excep.getMessage(),"System Manager",JOptionPane.INFORMATION_MESSAGE);
catch(ClassNotFoundException ex) {
JOptionPane.showMessageDialog(null,"Exception:" + ex,"ERROR",JOptionPane.ERROR_MESSAGE);
ex.printStackTrace();
catch(Exception e) {
JOptionPane.showMessageDialog(null,"Exception:" + e,"ERROR",JOptionPane.ERROR_MESSAGE);
public Connection getConnection() throws SQLException, IOException {
try {
Properties props = new Properties();
try {
String currentPath = getClass().getResource("a.Properties").getPath();
String abc=currentPath;
if(abc.indexOf('%')>0) {
String temp=abc.substring(0,abc.indexOf('%'));
int x=abc.indexOf('%')+3;
String temp1=abc.substring(x,abc.length());
currentPath=temp+" "+temp1;
props.load(new FileInputStream(currentPath));
String drivers = props.getProperty("jdbc.drivers");
if (drivers != null)
System.setProperty("jdbc.drivers", drivers);
url = props.getProperty("jdbc.url");
username = props.getProperty("jdbc.username");
password = props.getProperty("jdbc.password");
catch (IOException e) {
e.printStackTrace();
JOptionPane.showMessageDialog(null, "Error in a.properties file.", "", JOptionPane.ERROR_MESSAGE);
catch(Exception e) {
e.printStackTrace();
return
DriverManager.getConnection(url, username, password);
Regards,
marcalena

Help! CORE DUMP file in our platform, WLS 6.1 SP7

Hi,
I am having a problem and it causes the weblogic server to terminate suddenly.
My configuration is:
- Weblogic 6.1 SP7
- Windows 2000
- Weblogic Oracle Driver (weblogic.jdbc.oci.Driver)
- Database Oracle 9i
Pls help me to resolve this problem.... thanks in advance!
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x1CEA0090
Function name=kghalo
Library=g:\ora9i\bin\orageneric9.dll
Current Java thread:
at weblogic.db.oci.OciLob.assignLobFromColumn(Native Method)
at weblogic.db.oci.OciCursor.getValue(OciCursor.java:1199)
at weblogic.db.oci.OciCursor.getValue(OciCursor.java:1136)
at weblogic.db.oci.OciCursor.getValue(OciCursor.java:1130)
at weblogic.db.oci.OciCursor.getSelectValue(OciCursor.java:1052)
at weblogic.jdbc.oci.ResultSet.getObject(ResultSet.java:856)
at weblogic.jdbc.oci.ResultSet.getObject(ResultSet.java:728)
at weblogic.jdbc.pool.ResultSet.getObject(ResultSet.java:369)
at sg.gov.dsta.gebiz.entreports.admin.util.AdminUtil.getClobValue(AdminUtil.java:665)
at sg.gov.dsta.gebiz.entreports.admin.dao.AdminApprovalRulesDAO.getMaintainApprovalRulesList(AdminApprovalRulesDAO.java:118)
at sg.gov.dsta.gebiz.entreports.admin.handler.AdminInternHandler.getMaintainApprovalRuleList(AdminInternHandler.java:86)
at sg.gov.dsta.gebiz.entreports.admin.handler.AdminInternHandler.getSearchListing(AdminInternHandler.java:47)
at sg.gov.dsta.gebiz.entreportsweb.admin.action.ABAdminSearchAction.execute(ABAdminSearchAction.java:147)
at sg.gov.dsta.gebiz.entreportsweb.admin.action.ABApprovalRule.execute(ABApprovalRule.java:37)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:288)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at sg.gov.sco.gebiz.filters.XSSFilter.doFilter(XSSFilter.java:153)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069)
at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:288)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at sg.gov.sco.gebiz.filters.XSSFilter.doFilter(XSSFilter.java:153)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2771)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2462)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:172)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:145)
Dynamic libraries:
0x00400000 - 0x00405000 I:\jdk1.3.1_12\bin\java.exe
0x77F80000 - 0x77FFC000 C:\WINNT\system32\ntdll.dll
0x7C2D0000 - 0x7C335000 C:\WINNT\system32\ADVAPI32.dll
0x7C570000 - 0x7C623000 C:\WINNT\system32\KERNEL32.dll
0x77D30000 - 0x77DA8000 C:\WINNT\system32\RPCRT4.dll
0x78000000 - 0x78045000 C:\WINNT\system32\MSVCRT.dll
0x6D420000 - 0x6D4FB000 I:\jdk1.3.1_12\jre\bin\hotspot\jvm.dll
0x77E10000 - 0x77E79000 C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000 C:\WINNT\system32\GDI32.dll
0x77570000 - 0x775A0000 C:\WINNT\system32\WINMM.dll
0x6D220000 - 0x6D227000 I:\jdk1.3.1_12\jre\bin\hpi.dll
0x6D3B0000 - 0x6D3BD000 I:\jdk1.3.1_12\jre\bin\verify.dll
0x6D250000 - 0x6D268000 I:\jdk1.3.1_12\jre\bin\java.dll
0x6D3C0000 - 0x6D3CD000 I:\jdk1.3.1_12\jre\bin\zip.dll
0x6D340000 - 0x6D348000 I:\jdk1.3.1_12\jre\bin\net.dll
0x75050000 - 0x75058000 C:\WINNT\system32\WSOCK32.dll
0x75030000 - 0x75044000 C:\WINNT\system32\WS2_32.DLL
0x75020000 - 0x75028000 C:\WINNT\system32\WS2HELP.DLL
0x782C0000 - 0x782CC000 C:\WINNT\System32\rnr20.dll
0x77980000 - 0x779A4000 C:\WINNT\system32\DNSAPI.DLL
0x77340000 - 0x77353000 C:\WINNT\system32\iphlpapi.dll
0x77520000 - 0x77525000 C:\WINNT\system32\ICMP.DLL
0x77320000 - 0x77337000 C:\WINNT\system32\MPRAPI.DLL
0x75150000 - 0x75160000 C:\WINNT\system32\SAMLIB.DLL
0x7CDC0000 - 0x7CE13000 C:\WINNT\system32\NETAPI32.DLL
0x751C0000 - 0x751C6000 C:\WINNT\system32\NETRAP.dll
0x77BF0000 - 0x77C01000 C:\WINNT\system32\NTDSAPI.dll
0x77950000 - 0x7797B000 C:\WINNT\system32\WLDAP32.DLL
0x7C340000 - 0x7C34F000 C:\WINNT\system32\SECUR32.DLL
0x7CE20000 - 0x7CF0F000 C:\WINNT\system32\OLE32.DLL
0x779B0000 - 0x77A4B000 C:\WINNT\system32\OLEAUT32.DLL
0x773B0000 - 0x773DF000 C:\WINNT\system32\ACTIVEDS.DLL
0x77380000 - 0x773A3000 C:\WINNT\system32\ADSLDPC.DLL
0x77830000 - 0x7783E000 C:\WINNT\system32\RTUTILS.DLL
0x77880000 - 0x7790E000 C:\WINNT\system32\SETUPAPI.DLL
0x7C0F0000 - 0x7C154000 C:\WINNT\system32\USERENV.DLL
0x774E0000 - 0x77514000 C:\WINNT\system32\RASAPI32.DLL
0x774C0000 - 0x774D1000 C:\WINNT\system32\rasman.dll
0x77530000 - 0x77552000 C:\WINNT\system32\TAPI32.dll
0x71710000 - 0x71794000 C:\WINNT\system32\COMCTL32.DLL
0x70A70000 - 0x70AD6000 C:\WINNT\system32\SHLWAPI.DLL
0x77360000 - 0x77379000 C:\WINNT\system32\DHCPCSVC.DLL
0x777E0000 - 0x777E8000 C:\WINNT\System32\winrnr.dll
0x777F0000 - 0x777F5000 C:\WINNT\system32\rasadhlp.dll
0x1CE00000 - 0x1CE55000 I:\bea\wlserver6.1\bin\oci920_8\weblogicoci37.dll
0x1CE60000 - 0x1CE7D000 g:\ora9i\bin\OCI.dll
0x780A0000 - 0x780B2000 C:\WINNT\system32\MSVCIRT.dll
0x60600000 - 0x60784000 g:\ora9i\bin\OraClient9.Dll
0x610A0000 - 0x6113F000 g:\ora9i\bin\oracore9.dll
0x612A0000 - 0x61319000 g:\ora9i\bin\oranls9.dll
0x613A0000 - 0x613B1000 g:\ora9i\bin\oraunls9.dll
0x60800000 - 0x60806000 g:\ora9i\bin\oravsn9.dll
0x60500000 - 0x60590000 g:\ora9i\bin\oracommon9.dll
0x1CE80000 - 0x1D0D7000 g:\ora9i\bin\orageneric9.dll
0x62FC0000 - 0x6303D000 g:\ora9i\bin\oraxml9.dll
0x630F0000 - 0x63110000 g:\ora9i\bin\oraxsd9.dll
0x615A0000 - 0x61629000 g:\ora9i\bin\orannzsbb9.dll
0x61480000 - 0x61534000 g:\ora9i\bin\oran9.dll
0x61400000 - 0x6142C000 g:\ora9i\bin\oranl9.dll
0x61960000 - 0x61971000 g:\ora9i\bin\oranldap9.dll
0x62000000 - 0x62024000 g:\ora9i\bin\oraldapclnt9.dll
0x616B0000 - 0x616C7000 g:\ora9i\bin\orancrypt9.dll
0x62300000 - 0x6233E000 g:\ora9i\bin\ORATRACE9.dll
0x61730000 - 0x61766000 g:\ora9i\bin\oranro9.dll
0x617C0000 - 0x617C6000 g:\ora9i\bin\oranhost9.dll
0x617D0000 - 0x617D6000 g:\ora9i\bin\oranoname9.dll
0x616A0000 - 0x616A6000 g:\ora9i\bin\orancds9.dll
0x61820000 - 0x61827000 g:\ora9i\bin\orantns9.dll
0x64000000 - 0x64007000 g:\ora9i\bin\oranms.dll
0x64020000 - 0x64030000 g:\ora9i\bin\oranmsp.dll
0x60A00000 - 0x60D13000 g:\ora9i\bin\orapls9.dll
0x62500000 - 0x62507000 g:\ora9i\bin\oraslax9.dll
0x61350000 - 0x61360000 g:\ora9i\bin\orasnls9.dll
0x60810000 - 0x60816000 g:\ora9i\bin\orawtc9.dll
0x62600000 - 0x62675000 g:\ora9i\bin\orasql9.dll
0x61910000 - 0x6191C000 g:\ora9i\bin\orantcp9.dll
0x74FD0000 - 0x74FEE000 C:\WINNT\system32\msafd.dll
0x75010000 - 0x75017000 C:\WINNT\System32\wshtcpip.dll
0x20260000 - 0x20265000 I:\bea\wlserver6.1\bin\oci920_8\weblogicoxa37.dll
0x6D240000 - 0x6D246000 I:\jdk1.3.1_12\jre\bin\ioser12.dll
0x20910000 - 0x20915000 I:\bea\wlserver6.1\bin\wlntio.dll
0x77920000 - 0x77943000 C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
0x690A0000 - 0x690AB000 C:\WINNT\system32\PSAPI.DLL
Local Time = Mon May 29 14:58:57 2006
Elapsed Time = 861
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Client VM (1.3.1_12-b03 mixed mode)
#

I would do all I could to avoid OCI-based
JDBC. OCI bugs can kill an entire JVM.
I would use the Oracle thin driver.
Joe

Problem using IntegerSubclassProvider

SORRY - I got the title wrong in the previous post so here it is again so
people can search more easily.
I have just switched to use the above class. Lots of my unit tests work, but
when loading some data to initialie our application I get this:
com.solarmetric.kodo.runtime.DataStoreException: Type "4" is referenced in
the database, but does not exist.
at
com.solarmetric.kodo.impl.jdbc.ormapping.IntegerSubclassProvider.getType(Int
egerSubclassProvider.java:207)
at
com.solarmetric.kodo.impl.jdbc.ormapping.SubclassProviderImpl.getType(Subcla
ssProviderImpl.java:97)
at
com.solarmetric.kodo.impl.jdbc.ormapping.ClassMapping.loadPrimaryMappings(Cl
assMapping.java:1108)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.initialize(JDBCStore
Manager.java:334)
at
com.solarmetric.kodo.runtime.datacache.DataCacheStoreManager.initialize(Data
CacheStoreManager.java:523)
at
com.solarmetric.kodo.runtime.StateManagerImpl.loadInitialState(StateManagerI
mpl.java:215)
at
com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectByIdFilter(Pers
istenceManagerImpl.java:1310)
at
com.solarmetric.kodo.runtime.PersistenceManagerImpl.getObjectById(Persistenc
eManagerImpl.java:1228)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.createFromResultSet(
JDBCStoreManager.java:916)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager$3.getResultObject(JD
BCStoreManager.java:1095)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:199)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:421)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
at
com.solarmetric.kodo.impl.jdbc.runtime.ResultListFactory.createResultList(Re
sultListFactory.java:107)
at
com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.executeQuery(JDBCSto
reManager.java:1087)
at
com.solarmetric.kodo.impl.jdbc.query.JDBCQuery.executeQuery(JDBCQuery.java:1
26)
at
com.solarmetric.kodo.query.QueryImpl$DatastoreQueryExecutor.executeQuery(Que
ryImpl.java:1554)
at
com.solarmetric.kodo.query.QueryImpl.executeQueryWithMap(QueryImpl.java:675)
at
com.solarmetric.kodo.query.QueryImpl.executeWithMap(QueryImpl.java:540)
at
com.solarmetric.kodo.query.QueryImpl.executeWithArray(QueryImpl.java:526)
at com.solarmetric.kodo.query.QueryImpl.execute(QueryImpl.java:496)
at
com.solarmetric.kodo.runtime.datacache.query.CacheAwareQuery.execute(CacheAw
areQuery.java:273)
at
com.cloverworxs.impl.jdo.MutableModelManagerImpl.findByURI(MutableModelManag
erImpl.java:147)
at
com.cloverworxs.impl.as.security.SecuritySetup.setUp(SecuritySetup.java:96)
at
com.cloverworxs.impl.as.security.SecuritySetup.main(SecuritySetup.java:81)
My metadata has a class of type "4" as shown below:
<jdo>
<package name="com.cloverworxs.blah">
<class name="BlahClass"
persistence-capable-superclass="com.cloverworxs.blah.Super">
<extension vendor-name="kodo" key="subclass-indicator-value" value="4"/>
And using the same core classes the offending data has been loaded into the
system sucessfully in the previos step, as that step works, and I look in
the table and see a number of rows, with differnt types, including type "4".
Any ideas?
I am using kodo 2.5.2 with MSSQL in this case.
Thanks, Matty.

I turned on the logging and it is reading the property as it complained
about my invalid class.
I turned on DEBUG on the same, and it appears to register the classes as it
comes across them in the code, in various groups, rather than in one batch
at the start as I would expect with the property set.
I have now included explicit references to all the classes in a static
initializer of one of our core classes, and it works fine, each class being
listed by the debug as it gets registered.
So, for now I have a solution, but I feel that the
com.solarmetric.kodo.PersistentTypes property is not working correctly.
Below is a snippet of the trace for a run whene there are instances
persisten in the db. It shows that it does not seem to register the classes
as per the property because it only attempts to register one class before it
fails.
[java] 0 [main] INFO solarmetric.kodo.Runtime - Starting Kodo
JDO version 2.5.2 (kodojdo-2.5.2-20030704-1910) with capab
ilities: [Enterprise Edition Features, Standard Edition Features, Lite
Edition Features, Query Extensions, Performance Pack, Stateme
nt Batching, Global Transactions, Custom Database Dictionaries, Enterprise
Databases]
[java] 0 [main] DEBUG solarmetric.kodo.Runtime -
[email protected]492: se
tup
[java] 265 [main] DEBUG solarmetric.kodo.Runtime -
[email protected]492: re
gistering 1 classes: [class
com.cloverworxs.impl.base.ke.model.MutableKObjectBase]
[java] 812 [main] WARN solarmetric.kodo.Runtime - The Microsoft
JDBC driver has bugs when re-using PreparedStatement insta
nces. Please disable the PreparedStatement pool when using the Microsoft
JDBC driver by setting the property "com.solarmetric.kodo.i
mpl.jdbc.StatementCacheMaxSize" to 0.
[java] 890 [main] DEBUG solarmetric.kodo.Runtime -
[email protected]492: re
gisterClass:
com.cloverworxs.impl.base.ke.model.MutableKObjectBase@c79809=>true
[java] com.solarmetric.kodo.runtime.FatalDataStoreException:
com.solarmetric.kodo.runtime.DataStoreException: Type "null", the
type registered for subclass indicatorvalue "4", is referenced in the
database, but does not exist.
[java] NestedThrowables:
Matty
"Abe White" <[email protected]> wrote in message
news:[email protected]...
>>
com.solarmetric.kodo.PersistentTypes=com.cloverworxs.Blah,com.cloverworxs.Bl
ah2
Correct?Looks right to me. Are you sure that you put it in the right properties
file? With invalid classes, you should see warnings outputted to the
com.solarmetric.kodo.Runtime log channel at the WARN level. If you enable
logging and don't see any warnings, then something is indeed amiss with
the setup.

Oracle thin JDBC driver BUG-2285052, how to solve it ?

Hi, use ResultSet.getString to get a nchar type String from databaase, it will return the proper value.
eg, a 254 size column , it will return more char as needed !!
please check next from jdbc readme file. anyone can give me a temp solution ?
BUG-2285052 (since 9.2.0.1)
Extra space and null characters are returned by ResultSet.getString() and Scrollable ResultSet getString() for NCHAR column when the database national character set is UTF8. This behavior occurs only with JDBC THIN driver.

Dear Michael,
thx I found a lot of useful properties via the links you provided, but not those in question.
michael_obrien wrote:
For timeouts, you may need to use a hint directly on the entity though
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#How_to_Use_EclipseLink_JPA_Query_Hints
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Timeout
I think this refers to "Statement.setQueryTimeout".
The properties I'm looking for focus on the connection and the network beneath.
Are there other undocumented ;) possibilities?
Kind Regards,
daniela

Bug in Oracle JDBC Pooling Classes - Deadlock

We are utilizing Oracle's connection caching (drivers 10.2.0.1) and have found a deadlock situation. I reviewed the code for the (drivers 10.2.0.3) and I see the same problem could happen.
I searched and have not found this problem identified anywhere. Is this something I should post to Oracle in some way (i.e. Metalink?) or is there a better forum to get this resolved?
We are utilizing an OCI driver with the following setup in the server.xml
<ResourceParams name="cmf_toolbox">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>hidden</value>
</parameter>
<parameter>
<name>password</name>
<value>hidden</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:oci:@PTB2</value>
</parameter>
<parameter>
<name>connectionCachingEnabled</name>
<value>true</value>
</parameter>
<parameter>
<name>connectionCacheProperties</name>
<value>(InitialLimit=5,MinLimit=15,MaxLimit=75,ConnectionWaitTimeout=30,InactivityTimeout=300,AbandonedConnectionTimeout=300,ValidateConnection=false)</value>
</parameter>
</ResourceParams>
We get a deadlock situation between two threads and the exact steps are this:
1) thread1 - The OracleImplicitConnectionClassThread class is executing the runAbandonedTimeout method which will lock the OracleImplicitConnectionCache class with a synchronized block. It will then go thru additional steps and finally try to call the LogicalConnection.close method which is already locked by thread2
2) thread2 - This thread is doing a standard .close() on the Logical Connection and when it does this it obtains a lock on the LogicalConnection class. This thread then goes through additional steps till it gets to a point in the OracleImplicitConnectionCache class where it executes the reusePooledConnection method. This method is synchronized.
Actual steps that cause deadlock:
1) thread1 locks OracleImplicitConnectionClass in runAbandonedTimeout method
2) thread2 locks LogicalConnection class in close function.
3) thread1 tries to lock the LogicalConnection and is unable to do this, waits for lock
4) thread2 tries to lock the OracleImplicitConnectionClass and waits for lock.
***DEADLOCK***
Thread Dumps from two threads listed above
thread1
Thread Name : Thread-1 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x30267fe8 Waiting for Monitor Lock on 0x509190d8 Java Stack at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - waiting to lock 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at oracle.jdbc.pool.OracleImplicitConnectionCache.closeCheckedOutConnection(OracleImplicitConnectionCache.java:1330) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.runAbandonedTimeout(OracleImplicitConnectionCacheThread.java:261) - locked 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.run(OracleImplicitConnectionCacheThread.java:81)
thread2
Thread Name : http-7320-Processor83 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x509190d8 Waiting for Monitor Lock on 0x30267fe8 Java Stack at oracle.jdbc.pool.OracleImplicitConnectionCache.reusePooledConnection(OracleImplicitConnectionCache.java:1608) - waiting to lock 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleConnectionCacheEventListener.connectionClosed(OracleConnectionCacheEventListener.java:71) - locked 0x34d514f8> (a oracle.jdbc.pool.OracleConnectionCacheEventListener) at oracle.jdbc.pool.OraclePooledConnection.callImplicitCacheListener(OraclePooledConnection.java:544) at oracle.jdbc.pool.OraclePooledConnection.logicalCloseForImplicitConnectionCache(OraclePooledConnection.java:459) at oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:475) at oracle.jdbc.driver.LogicalConnection.closeInternal(LogicalConnection.java:243) at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - locked 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at com.schoolspecialty.cmf.yantra.OrderDB.updateOrder(OrderDB.java:2022) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:119) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:67) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.UpdateCartAction.perform(Unknown Source) at com.schoolspecialty.mvc2.ActionServlet.doPost(ActionServlet.java:112) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPostOrGet(Unknown Source) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at com.schoolspecialty.ecommerce.servlets.filters.EcommerceURLFilter.doFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)

We used a documented option to abandon connects in the case of an unforeseen error. The consequence of using this option was not a graceful degradation in performance but a complete lockup of the application. The scenario in which we created a moderate number of abandoned connections was a rare error scenario but a valid test.
How could this not be a bug in the Oracle driver? Is dead-lock a desireable outcome of using an option? Is dead-lock ever an acceptable consequence of using a feature as documented?
Turns out other Oracle options to recover from an unexpected error also incur a similar deadlock (TimeToLiveTimeout).
I did a code review of the decompiled drivers and it clearly shows the issue, confirming the original report of this issue. Perhaps you have evidence to the contrary or better evidence to support your statement "not a bug in Oracle"?
Perhaps you are one of the very few people who have not experience problems with Oracle drivers? I've been using Oracle since 7.3.4 and it seems that I have always been working around Oracle JDBC driver problems.
We are using Tomcat with the OracleDataSourceFactory.

Bug in Oracle JDBC thin driver (parameter order)

[ I'd preferably send this to some Oracle support email but I
can't find any on both www.oracle.com and www.technet.com. ]
The following program illustrates bug I found in JDBC Oracle thin
driver.
* Synopsis:
The parameters of prepared statement (I tested SELECT's and
UPDATE's) are bound in the reverse order.
If one do:
PreparedStatement p = connection.prepareStatement(
"SELECT field FROM table WHERE first = ? and second = ?");
and then bind parameter 1 to "a" and parameter to "b":
p.setString(1, "a");
p.setString(2, "b");
then executing p yields the same results as executing
SELECT field FROM table WHERE first = "b" and second = "a"
although it should be equivalent to
SELECT field FROM table WHERE first = "a" and second = "b"
The bug is present only in "thin" Oracle JDBC driver. Changing
driver to "oci8" solves the problem.
* Version and platform info:
I detected the bug using Oracle 8.0.5 server for Linux.
According to $ORACLE_HOME/jdbc/README.doc that is
Oracle JDBC Drivers release 8.0.5.0.0 (Production Release)
* The program below:
The program below illustrates the bug by creating dummy two
column table, inserting the row into it and then selecting
the contents using prepared statement. Those operations
are performed on both good (oci8) and bad (thin) connections,
the results can be compared.
You may need to change SID, listener port and account data
in getConnecton calls.
Sample program output:
$ javac ShowBug.java; java ShowBug
Output for both connections should be the same
--------------- thin Driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
[ The same - with buggy reversed order (should give no answers):
aaa
--------------- oci8 driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
aaa
[ The same - with buggy reversed order (should give no answers):
--------------- The end ---------------
* The program itself
import java.sql.*;
class ShowBug
public static void main (String args [])
throws SQLException
// Load the Oracle JDBC driver
DriverManager.registerDriver(new
oracle.jdbc.driver.OracleDriver());
System.out.println("Output for both connections should be the
same");
Connection buggyConnection
= DriverManager.getConnection
("jdbc:oracle:thin:@localhost:1521:ORACLE",
"scott", "tiger");
process("thin Driver", buggyConnection);
Connection goodConnection
= DriverManager.getConnection ("jdbc:oracle:oci8:",
"scott", "tiger");
process("oci8 driver", goodConnection);
System.out.println("--------------- The end ---------------");
public static void process(String title, Connection conn)
throws SQLException
System.out.println("--------------- " + title + "
Statement stmt = conn.createStatement ();
stmt.execute(
"CREATE TABLE bug (id VARCHAR(10), val VARCHAR(10))");
stmt.executeUpdate(
"INSERT INTO bug VALUES('aaa', 'bbb')");
System.out.println("[ Non parametrized query: ]");
ResultSet rset = stmt.executeQuery(
"select id from bug where id = 'aaa' and val = 'bbb'");
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - parametrized (should give one
row): ]");
PreparedStatement prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "aaa");
prep.setString(2, "bbb");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - with buggy reversed order
(should give no answers): ]");
prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "bbb");
prep.setString(2, "aaa");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
stmt.execute("DROP TABLE bug");
null

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

A BUG in the KPRB JDBC driver

Hi community,
the problem I would like to present here seems to be a BUG in the KPRB (server-side) JDBC driver. To be precise, I am going to outline the platform I found the problem occurs (I haven't made any tests with the others yet). These are Oracle 8.1.6-8.1.7.4 databases.
What I am trying to do is to write a Java Stored Procedure and return a nested table from it. Nothing easier than that!? The important aspect is I cannot (shouldn't) hardcode schema name in the call to the oracle.sql.ArrayDescriptor.createDescriptor() method since the Stored Procedure and the accompanied nested table (SQL) type can be loaded into arbitrary schema. Thus, my code looks like:
Connection con = DriverManager.getConnection("jdbc:default:connection:");
ArrayDescriptor arrDesc = ArrayDescriptor.createDescriptor("NESTED_TABLE_TYPE_NAME",con);
You can note, NESTED_TABLE_TYPE_NAME is the nested table type I create in the same schema the Stored Procedure is loaded. What wrong with it? Actually, it works perfectly fine if You call the Stored Procedure being logged as the owner of the Procedure. The problem occurs if You grant the execute rights to other users and try to call it being logged as one of them. What happens is Oracle doesn't find the nested table type and throws an exception.
Does it mean such behavior implies a BUG? Oracle reference states that if either the PL/SQL wrapper for the Java Stored Procedure or the class itself are marked as having DEFINER privileges the call proceeds in the schema of the definer, not the caller. Actually, I tried to declare the PL/SQL wrapper as well as the class having DEFINER privileges and none of them succeded.
Then I made some investigations, and found in the Thin JDBC driver the ArrayDescriptor.createDescriptor method uses the oracle.sql.SQLName class, which in turn calls the oracle.jdbc.driver.OracleConnection.getUserName() method to obtain the missing schema name, and the latter performs select:
SELECT USER FROM DUAL
Obviously, the above returns current user, and not the current schema in the case DEFINER privileges were applied. I understand, the Thin JDBC driver is different from the KPRB driver but!!! I also monitor Library Cache (through v$sql dynamical view) while calling the Stored Procedure and what I see is very interesting ;-) The number of executions for the "SELECT USER FROM DUAL" statement increases!!!
That is why I claim the above behavior is a BUG of the KPRB driver.
Regards,
Roman Zahorbenski

Hi Avi,
Because you didn't grant access permission to other users on the NESTED_TABLE_TYPE_NAME (maybe?)Of course, I remember to grant (EXECUTE) privilege on the nested table type to other users. The reason are not synonyms also, for Oracle doesn't allow to access these types through synonyms, unfortunately.
And the applications can be tons ;-), I use it to implement regular expression functionality in the databases prior to 9i.
Regards,
Roman

Bug in Oracle JDBC Driver: NullPointerException when calling clearParameters

There is a bug in the latest version of the JDBC driver that throws a NPE when calling PreparedStatement.clearParameters(). I don't need a response to this, since I have a workaround (just catching and ignoring the exception), but it should probably be fixed. I speculate that the problem only occurs when you try to call clearParameters() more than once on the same PS, but I haven't confirmed it.
It is probably an easy fix. Following is the stack trace:
java.lang.NullPointerException
at oracle.jdbc.dbaccess.DBData.clearItem(DBData.java:431)
at oracle.jdbc.dbaccess.DBDataSetImpl.clearItem(DBDataSetImpl.java:3528)
at oracle.jdbc.driver.OraclePreparedStatement.clearParameters(OraclePreparedStatement.java:3401)
at com.solarmetric.datasource.PreparedStatementCache$CachePreparedStatement.close(PreparedStatementCache.java:293)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatementBatch(SQLExecutionManagerImpl.java:666)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatement(SQLExecutionManagerImpl.java:514)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeInternal(SQLExecutionManagerImpl.java:406)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.flush(SQLExecutionManagerImpl.java:273)
at com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.flush(JDBCStoreManager.java:421)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.flush(PersistenceManagerImpl.java:549)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:412)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId2(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.runTest(Unknown Source)
at com.sun.jdotck.api.persistencemanager.PersistenceManagerTest.run(Unknown Source)
at com.solarmetric.kodo.compatibility.JDOCompatabilityTestSuite$1.runTest(JDOCompatabilityTestSuite.java:493)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Take a look at the method that is causing the NullPointerException:
public void clearItem(int i)
if (!m_dynamic && m_vector == null && i < m_vector.size())
m_vector.removeElementAt(i);
if (m_items != null && i >= m_items.length)
return;
m_items[i] = null;
return;
A NullPointerException will be thrown whenever clearParameters() is called when no parameters have yet been bound.
The first IF statement should read:
if (!m_dynamic && m_vector != null && i < m_vector.size())
A simple workaround would be to make sure that your parameter list is never empty before calling clearParameters(). Is there a patch for this anywhere?

Bug in Oracle JDBC thin driver 8.1.6 ?

Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Is this a bug in JDBC driver for SQL Server 2000?

Hi, all:
I encountered a strange problem today.
My struts/jsp application throws an error while executing the following SQL:
SELECT id,moduleName,pageLevel,ent_name,style_name,type,hits,startDate,expireDate,expireAction,active,dealtime FROM v_ad WHERE style_id=1 ORDER BY id DESC
The error message is:
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Invalid column name 'style_id'.
However, the column "style_id" does exist in view "v_ad", and if I execute this query in SQL Server Query Analyzer, it runs rightly with my expected result.
I wonder if this is a bug of JDBC, and if this is really a bug, how should I deal with this problem?
Any help would be thankful!

Sounds like you may not have connected to the right database on the server.
Check the default database for the username/passwd combo you are logging in with.

Big bug in NW-PI-731, JDBC-adapter losing data

Hi,
we recognized a big bug in NW-PI-731 SPS07, processing data with JDBC_xxxx_SENDER, sometimes it occurs, that for example, from 13974 documents should be processed, but only a part of 13137 documents are processed successfully, but 837 documents are missing in the target system,
In message-monitoring, PI displays all documents as processed successfully, but that is obviously wrong,
so PI is sometimes losing data - this behaviour we did not have had in NW-PI-700-SPS18
after upgrading to PI-731, we have big trouble with data processing.
did other SAP-customers noticed the same behaviour?

Hi
You can count the total number message processed in PI from message monitoring in RWB.
If you see that the number is 13137, then there is a problem while reading the data from database
using JDBC sender adapter.
Since the number of records are high, you can try to restrict the number of records using rownum in
database select query.
Check this
PI 7.1 JDBC sender adapter huge load from DB se... | SCN
PI JDBC Sender adapter - Some Learnings

JDBC 4.0 Bug

Similar Messages

Maybe you are looking for