JDBC 10.1.0.2.0 bug

When calling the JDBC DatabaseMetaData method getJDBCMajorVersion() using the latest ojdbc14_g.jar file, this method returns a value of 10. However, the JDBC driver docs say the value returned by this function should reflect the "JDBC major version number" for this driver. Since the current JDBC version is 3.0, it's hard to see how this value could be > 3. But, it appears that the driver writer has assumed this number should reflect the driver's version number and not the JDBC version which, to my knowledge, is incorrect and likely to confuse any code that is calling this method to determine what JDBC revision level is supported by this driver.
Wayne

if ( ( OracleDatabaseMetaData.class.getDeclaredMethod("getJDBCMajorVersion",null ).
getSystematicReturnValue() == DRIVER_MAJOR_VERSION )
&& ( OracleDriver.class.getDeclaredMethod("jdbcCompliant",null ).
getSystematicReturnValue() == true ) ) {
throw ORACLE_BLATANT_ARROGANCE_AGAIN_EXCEPTION ;

Similar Messages

Oracle JDBC 8.1.7 XA prepare bug

Both Oracle JDBC 8.1.7 XA thin and oci drivers have a bug related to
the prepare fase of 2PC.
In some circunstances when loosing connection, the prepare fase cannot
be completed
but Oracle driver returns a successfull status, so WLS issues second
phase of commit
when it shouldn't. This is a known bug on Oracle.
Josep Blazquez.

http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html
Btw: the Oracle homepage does have a search function which will find that page using "download jdbc driver" as the search criteria.

JDBC 8.1.6.0.1 Bug with grouping function

Hi,
I found a bug in the JDBC 8.1.6.0.1 driver, concerning the new grouping functionality of Oracle 8.1.6. Look at the following code fragment:
String cSelect = "SELECT DACO_VU_NAME AS DIM1, ' ' AS DIM2, TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm') AS DIM_DATE, GROUPING(DACO_VU_NAME) AS DIM1GROUP, GROUPING(' ') AS DIM2GROUP, GROUPING(TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm')) AS DIM_DATEGROUP, sum(DACO_BRUTTOBETRAG_TX) AS VALUE FROM DATENCONTAINER GROUP BY CUBE (DACO_VU_NAME, '-', TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm') ) ORDER BY 1,2,3";
try {
System.out.println("SELECT: " + cSelect);
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery(cSelect);
while (rset.next()) {
String cTest1 = rset.getString("DIM1");
String cTest2 = rset.getString("DIM2");
String cTest3 = rset.getString("DIM_DATE");
String cChar1 = rset.getString("DIM1GROUP");
String cChar2 = rset.getString("DIM2GROUP");
String cChar3 = rset.getString("DIM_DATEGROUP");
System.out.println(cTest1 + "\t" + cTest2 + "\t" + cTest3 + "\t" + cChar1 + "\t" + cChar2 + "\t" + cChar3);
}When I compile this with the mentioned JDBC version and run it with java 1.2.2 (JDeveloper 3.1), i get the following output:
Ahrend GmbH & Co. KG 200003 0 0 0
Ahrend GmbH & Co. KG 200003 1 0 0
Ahrend GmbH & Co. KG 200004 0 0 0
Ahrend GmbH & Co. KG 200004 1 0 0
Ahrend GmbH & Co. KG null 0 0 1
Ahrend GmbH & Co. KG null 1 0 1
null 200003 0 1 0
null 200003 1 1 0
null 200004 0 1 0
null 200004 1 1 0
null null 0 1 1
null null 1 1 1As you can see, the grouping columns are mixed up. In this example, everywhere a normal row shows a "null" value, a corresponding grouping row should show a "1", but as you can see, for the last 6 rows, the ones are not in the first, but in the second grouping row.
When I compile the example with the Oracle 8.1.5 JDBC driver, I get the following, correct, output:
Ahrend GmbH & Co. KG 200003 0 0 0
Ahrend GmbH & Co. KG 200004 0 0 0
Ahrend GmbH & Co. KG null 0 0 1
Ahrend GmbH & Co. KG 200003 0 1 0
Ahrend GmbH & Co. KG 200004 0 1 0
Ahrend GmbH & Co. KG null 0 1 1
null 200003 1 0 0
null 200004 1 0 0
null null 1 0 1
null 200003 1 1 0
null 200004 1 1 0
null null 1 1 1The special thing about this example is, that I use a constant row for grouping (row 2). If you use a normal database row, everything works fine with 8.1.6.0.1, but nevertheless, this should be a bug.
Any comments on this are highly appreciated, since I need the JDK 1.2 for the application and I didn't find a working Oracle 1.2 JDBC version.
Thanks,
Thorsten.

Patches can be obtained from an Oracle Support Services technical analyst.
null

A bug in creator when creating jdbc jndi connection

Hi,
I am using sun java studio creator for jdbc jndi connection. The syntax is
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/mydb");
conn = ds.getConnection();
It's failed. Once I change to ctx.lookup("jdbc/mydb") and the connection is created.
Once deployed to tomcat, it seems only java:comp/env/jdbc/mydb is working.
The full path(java:comp/env/jdbc/mydb) seems right from my google search.
Why creator using jdbc/mydb? Is it a bug to creator?
Thanks,
Jie

I mean a resource reference in web.xml file that looks like this:
     <resource-ref id="ResourceRef_1103225373500">
          <res-ref-name>DBConnection</res-ref-name>
          <res-type>javax.sql.DataSource</res-type>
          <res-auth>Application</res-auth>
          <res-sharing-scope>Shareable</res-sharing-scope>
     </resource-ref>
where DBConnection is the resource alias I mentioned before:
DataSource ds = (DataSource)ctx.lookup("java:comp/env/DBConnection");
Using WebSphere a binding between this above defined ResourceRef and JNDI mapping must be defined in a file called ibm-web-bnd.xmi. The content of this file will look like this:
<?xml version="1.0" encoding="UTF-8"?>
<webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappbnd="webappbnd.xmi" xmi:id="WebAppBinding_1" virtualHostName="default_host">
<webapp href="WEB-INF/web.xml#WebApp"/>
<resRefBindings xmi:id="ResourceRefBinding_1103225373500" jndiName="jdbc/mydb">
<bindingResourceRef href="WEB-INF/web.xml#ResourceRef_1103225373500"/>
</resRefBindings>
</webappbnd:WebAppBinding>
Obviously using WSAD all of that could be done using IDE. In your case and using Sun IDE, I am not sure. But this is basically the concept of needed mapping in order to reference your JNDI without getting an error. At least this is how we resolved the error you are encountering.
Hope that helps!

JDBC: Prepared statements with more parameters than column names

I'm using the latest version of the JDBC driver - 4.1.5605.100_enu - on Java 1.7, Linux.
I'm connecting to MS SQL Server 2012 Express Edition using a connection URL of the form jdbc:sqlserver://10.0.0.2;user=username;password=pwd;database=testdb1
I have a table with two columns. One is an ID (type bigint) and one is numeric(38, 19).
The following code works exactly as expected:
PreparedStatement stm = connection.prepareStatement("INSERT INTO myTable(id, num) VALUES (?, ?)")
// repeatedly set parameters using setLong, setBigDecimal, then addBatch
stm.executeBatch()
The following code does not work as expected:
PreparedStatement stm = connection.prepareStatement("INSERT INTO myTable(id, num) VALUES (?, ?), (?, ?)");
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setBigDecimal(4, new BigDecimal("1.234"));
stm.addBatch();
stm.executeBatch();
The code runs normally in the second case, but the second row inserted contains the wrong value in the "num" column - it's been rounded to 1.0 instead of stored as 1.234.
I think this may be because the driver does not understand the types of parameters whose indexes are beyond the number of columns in the insert statement. Running the following code on the second prepared statement:
System.err.println(stm.getParameterMetaData().getParameterTypeName(2)); // prints "numeric"
System.err.println(stm.getParameterMetaData().getParameterTypeName(4)); // fails with IndexOutOfBoundsException
As far as I can tell from the JDBC JavaDoc, this usage is valid and ought to work. Certainly it works as expected (including the parameter metadata) using PostgreSQL and their JDBC driver. Is this a bug in Microsoft's driver?

Hi dtn-cfl,
Thanks for your waiting.
Based on my research(using
SQL Server Profiler to trace DB events), the preparedStatement finally passes the below statements to SQL Server.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setNull(4, Types.DECIMAL);
declare @p1 int
set @p1=0
exec sp_prepexec @p1 output,N'@P0 bigint,@P1 decimal(38,3),@P2 bigint,@P3 decimal(38,0)',N'INSERT INTO myTable(id, num) VALUES (@P0, @P1), (@P2, @P3) ',1,1.234,2,NULL
select @p1
Pay attention to the @P3 decimal(38,0), it seems(I don't have access to JDBC source code so that I have to use seem) that the
stm.setNull(4, Types.DECIMAL) will finally parsed as a type decimal(38,0). In SQL Server, to a
decimal datatype，one with smaller scale has a higher precedence. To understand the precedence， please see below code. If you have more interest in data type precedence, you can click
here.
declare @num1 decimal(38,3) --scale 3
declare @num2 decimal(38,2) --scale 2
set @num1 = 3.225
set @num2 = 3.22
select @num1 as num
union all
select @num2
output
num
3.23
3.22
@num1 get rounded to keep the column data type consistency, namely keep the column as type decimal(38,2)
Let's go back to your code, if you would like to make your code work properly, please see below.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setNull(4, Types.INTEGER);As per the above data type precedence link, a decimal has a higher precedence than integer, so your decimal will not get rounded.
Not only the case in your post, but also any data type inconsistency will lead to the rounding problem. See below.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setBigDecimal(4, new BigDecimal("1.2")); // or new BigDecimal("1.23") and any other decimal with different scale leads to rounding problem.
So when you set parameters for a prepareStatement like "INSERT INTO myTable(id, num) VALUES (?, ?), (?, ?)" with more than one row, you should pay attention to data type consistency fact.
The Microsoft JDBC driver for SQL Server may not be that intelligent, however we can't say that is a bug definitely.
If you have any question, feel free to let me know.
Eric Zhang
TechNet Community Support

JDBC/Cold Fusion to 8.1.6 DB

I'm using the 8.1.7 JDBC client on a Win2K Cold Fusion Server. The client connects to the database, but frequently hangs in the midst of a simple query. When I look at the task manager in Windows, the jrun process has maxed out at 99% with very little RAM being used. I'm trying to figure if this is a JDBC problem or a java runtime bug.
anyone have suggestions?

Update: I am running the rmjvm.run( true ) procedure to remove the jvm install. This is hanging as well. It creates the 'MONSTER' rollback segment, via the initjvmaux.rollbacksetup call, but then hangs (it appears) after that...I'll let it run a bit longer but this getting very frustrating is to say the least (of course, I have said more @()$*&@$(*#&!!!).
If I do a fresh install on the same machine, same parameters, and everything works then Oracle needs to work on their conversion utilities...and I thought their problems were just limited to their GUI tools...oh well. Oh yeah, perhaps a class action lawsuit against big O for loss of productivity because their conversion utility didn't work as documented. Don't get me wrong, best DB on the market, unfortunely, that's where their success ends in my opinion.

JDBC-ODBC Bridge is too slow

Why the Sun JDBC-ODBC Bridge is so slow? When i use the ms bridge it is as faster than a JDBC connection, but i found a bug on the ms bridge that it returns NULL when the value is a "" (blank)
Anyone how to make sun bridge has a acceptable perfomance?
I am using MySQL 3.23 and tested on Sun JDKs 1.1.8, 1.2, 1.4
My comp is a K6-2 400 with 128 RAM
Thanks

isjm said
   I've found using a pure JDBC driver (ashna's JTurbo) to be
   roughly 40% faster than the bridge after doing some
   (admitidly) small amount of bench testing. I also found
   it resolved a number of issues (bugs??) with the bridge
   (e.g. no longer throws an occasional fractional truncation
   exception when inserting timestamps). As for the bridge
   being used only for test purposes check out this URL:
   http://java.sun.com/J2se/1.3.0/docs/guide/jdbc/getstart/bridge.doc.html
   They recommend using the bridge only for experimental use or when a
   pure driver is not available. I guess you could consider this as test purposes only.There is no such thing as a 'pure driver' (or 'pure jdbc driver' from a different post.)
The doc you site suggests a 'pure java' driver - a type 4. I question that. I know there are number of things that one can do in ODBC and in OCI which speed up requests. And obviously one can't do those in java.
Performance problems are caused by the following:
-Requirements-most impact
-Design
-Environment (cpu,network,thread, etc bottlenecks)
-Language/intefaces - least impact.
Changing requirements/design can easily produce impacts of orders of magnitude (by removing one requirement I reduce a 4-8 hour report to less than 30 seconds.) So how much impact did the 40% you saw impact your total application? Did you profile your application/system under load using a automated tool to measure the speed?
I would suspect also that the suggestion that the driver is 'experimental use or when no other alternative is available' might be slightly biased as the driver was produced by Merant who is actively selling drivers too. One would suppose that they were not allowed to deliberately introduce bugs into the code. However, they might have insisted that some language be introduced to suggest that someone should buy the product.
anarquia said
   But i can't believe i've tested today again and the sun
   bridge is working as fast the ms bridge! i can't
   understand, yesterday i've tested a million times
   and it was about 30 times slower, i'll try to find
   what's happened yesterdayDid you use a closed network? Did you use isolated servers?

ORA-17002 IO Exceptions since Windows Vista

I just wanted to add a comment about the following dead thread that got locked after someone resurrected it:
The specified item was not found.
So Rüdiger, if you see this, please do not post to long dead threads. Open your own and reference the other question or discussion thread.
The new title I post here reflects the fact that this issue became much more prevalent after Microsoft made a fix in Vista that Oracle learned of through the following bug (logged against JDBC)
and SR (logged against Microsoft):
      Bug 9373409 - SUDDENLY JDBC THIN GOT CONNECTION ABORT ERROR ONLY WINDOWS 2008 OR VISTA ENV
and
     Microsoft's SR: SRF100225601418
       "This is expected behavior by the fix of winsock code since Vista.
       Windows has two different type of buffer for recv data (normal and
       urgent). Windows has only 16 packets buffer for urgent packet since
       Windows Vista. Because winsock layer was rewrote and the buffer was
       restricted for reduce memory-leak and urgent attack.
        4-1 This is hard-corded limitation. Therefore customer can not set the
          buffer size by registry.
       4-2 The workaround is recv MSG_OOB data on client (don't ignore)."
Assuming the ORA-17002 IO Exception applies both to connection aborts and break packets (as noted in the dead thread), then there are a couple of ways to proceed:
1. Disable Out Of Band Breaks (oracle.net.disableOob=true, either via AddVMOption in sqldeveloper.conf or via Java param -Doracle.net.disableOob=true)
2. Get the database patch for your version (11.2.0.2 in Rüdiger's case) as indicated in Bug 9373409. Otherwise it is fixed in 12.1.
Regards,
Gary
SQL Developer Team

Usman wrote:
>
Hi,
We are developing a JDBC application using WebLogic 6.0 as AppServer. When we
rolled out the application in production, things work fine for about a day or
so, then calls to Stored Procedures start giving ORA-17002 (io exception) and
ORA-17009 (Closed Statement) exceptions while calling Stored Procedures. Restarting
the server 'fixes' the problem for one more day.... We are not able to reproduce
this behaviour in test or development servers.
Can anybody suggest something.....
Regards,
Usman.Hi. Describe how you are obtaining and using pool connections. Also, do download the
latest thin driver from Oracle, because they have recently fixed some serious
bugs in it.
Let me know,
Joe

Reimport and Refresh Tables (MySQL DB adapter)

Hello.
I created DB adapter to MySQL DB in JDeveloper 11.1.1.5.
Everytime I open Adapter Configuration Wizard on this DB Adapter I get warning: Reimport and Refresh Tables.
"Some changes have been detected in the relational schema since these tables were imported. Please go back to the select tables page and reimport them. The changes are major enough that they can't be easily reconciled. The changes are: Table removed: ..." even there are not any changes in schema and tables still exists.
Is it a bug or feature?
I never saw this behaviour with Oracle DB. Is it a problem with MySQL JDBC driver?
Thanks

Looks like a bug to me. You should file an SR...
Timo

Oracle : User trace

Hi All,
This installation is a dual stack installation with usage type (EPC, EP). DB is unicode.
Today, I found following traces in the usertrace folder. These traces are
gcbepd:oraed3 43> pg ed3_ora_20913.trc
/oracle/ED3/saptrace/usertrace/ed3_ora_20913.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning and Data Mining options
ORACLE_HOME = /oracle/ED3/102_64
System name:    HP-UX
Node name:      gcbepd
Release:        B.11.23
Version:        U
Machine:        ia64
Instance name: ED3
Redo thread mounted by this instance: 0 <none>
Oracle process number: 0
Unix process pid: 20913, image: oracle@gcbepd
KCCDEBUG_LEVEL = 0
Dynamic strand is set to TRUE
Running with 2 shared and 0 private strand(s). Zero-copy redo is FALSE
gcbepd:oraed3 44>
gcbepd:oraed3 44> pg ed3_ora_20937.trc
/oracle/ED3/saptrace/usertrace/ed3_ora_20937.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning and Data Mining options
ORACLE_HOME = /oracle/ED3/102_64
System name:    HP-UX
Node name:      gcbepd
Release:        B.11.23
Version:        U
Machine:        ia64
Instance name: ED3
Redo thread mounted by this instance: 0 <none>
Oracle process number: 13
Unix process pid: 20937, image: oracle@gcbepd (TNS V1-V3)
SERVICE NAME:() 2008-06-06 13:01:11.276
SESSION ID:(84.1) 2008-06-06 13:01:11.276
kccsga_update_ckpt: num_1 = 50, num_2 = 0, num_3 = 0, lbn_2 = 0, lbn_3 = 0
gcbepd:oraed3 45>
This server has been installed on 30.05.08. These traces has come on 30.05.08 / 31.05.08 and today (06.06.08)
Any clue, why are these traces getting generated?
Please advise.
Thanks & Regards
Sudip

Hi Markus,
Thanks for reply.
Today I just did the following:
After I installed the Oracle patches (using MOPatch) on 31.05.08, one step was pending - replacing the jdbc drivers. (Ref. Oracle Bug: 5635254 SAP Note 1003198).
I went to folder /oracle/client/10x_64/instantclient and renamed the classes14.jar & ojdbc14.jar as .jar.old.........
and then again, renamed the .JAR files downloaded along with the patch 5635254 as classes14.jar & ojdbc14.jar in the same folder.
At this time, no SAP / Oracle processes were running. After the changes, I restarted the server.
Is there any problem in this?
Please advise.
Thanks & Regards
Sudip

Dynamically reload xml file

hi
What is the technique for dynamically change a xml source file (without changing the structure) for use with jdbc XML driver ?

see https://bugs.eclipse.org/bugs/show_bug.cgi?id=27980
Per Digre wrote:
> I need to dynamically set editor file extensions from a preference page.
> However I do not find any APIs to do this. It seems like it has to be
> loaded from the plugin.xml when the plugin initializes.
>
> One thing I thought of was following..
> 1. Create a add-on plugin just for the file extensions.
> 2. Manipulate the add-on's "plugin.xml" with new file extensions
> 3. Dynamically reload the add-on plugin to make the new extensions take
> effect
> Please stop me if I'm out of my mind!
>
>
> --- Per ---
>

Importing timestamp columns appears to use to_date instead of to_timestamp

I'm trying to import data (using the latest version 1.5.4 with Patch 2 applied) to an Oracle 10g database that contains timestamp columns. The input data has times with fractional (millisecond) values The data was exported using SQL Developer from a Sybase database and the timestamp format in the Excel (xls) file is YYYY-MM-DD HH24:MI:SS.FF3. When I specify this format for the TIMESTAMP columns on the import screens, the importer generates an insert statement like this:
INSERT INTO A (TMS) VALUES (to_date('2008-12-049 12:12:39.967', 'YYYY-MM-DD HH24:MI:SS.FF3'));
This command fails to execute with this error:
Error report:
SQL Error: ORA-01821: date format not recognized
01821. 00000 - "date format not recognized"
*Cause:
*Action:
I found that if to_timestamp is used instead of to_date, there is no issue inserting the row with the correct time precision. The question I have is why isn't SQL Developer using to_timestamp for importing a TIMESTAMP column, and should it?
Any advise woudl be appreciated.
Thanks

In 1.5.4 I see a bug where the "Format" field doesn't show up in the page in the import wizard, preventing the user from entering a mask when the column type is TIMESTAMP. This has been fixed in the code line under development and should be available when 2.1 gets released.
To give you a bit more detail on the confusing DATE/TIMESTAMP behaviour...
SQL Developer misrepresenting date as timestamp and vice versa stems from the behaviour of the Oracle JDBC driver. Following are the details I obtained from the JDBC team when I raised a bug("WRONG VALUE RETURNED FOR GETCOLUMNTYPE FOR DATE COLUMN ") on them:-
oracle.jdbc.mapDateToTimestamp is by default set
to true to indicate reporting DATE column as TIMESTAMP type. To turn off, pass
-Doracle.jdbc.mapDateToTimestamp=false" at the command line.
To effect this option in SQL Developer, you can add an AddVMOption -Doracle.jdbc.mapDateToTimestamp=false
A bit more history on the option:
8i and older Oracle databases did not support SQL TIMESTAMP, however Oracle
DATE contains a time component, which is an extension to the SQL standard. In
order to correctly handle the time component of Oracle DATE the 8i and
earlier drivers mapped Oracle DATE to java.sql.Timestamp. This preserved the
time component.
Oracle database 9.0.1 included support for SQL TIMESTAMP. In the process of
implementing support for SQL TIMESTAMP we changed the 9i JDBC driver to map
Oracle DATE to java.sql.Date. This was an incorrect decision since it
truncates the time component of Oracle DATE. There was also a backwards
compatibility problem trying to write java.sql.Timestamps to 8i databases.
These are separate problems but we "fixed" both under the control of a single
flag, V8Compatible. This flag was introduced in a 9.2 patch set.
By default the flag is false. When it is set to false the driver maps Oracle
DATE to java.sql.Date, losing the time component and it writes
java.sql.Timestamps to the database as SQL TIMESTAMPS. When the flag is set
to true the driver maps Oracle DATE to java.sql.Timestamp and writes
java.sql.Timestamps to the database as Oracle DATEs.
In 11.1 the V8Compatible flag was deprecated because it controlled Database
8i compatibility which is no longer supported. The additional behavior it
controlled, how SQL DATEs are handled, is controlled by a new flag,
mapDateToTimestamp. In 11.1 setting V8Compatible will just set
mapDateToTimestamp. This new flag only controls how SQL DATEs are
represented, nothing more. This flag will be supported for the foreseeable
future.
Finally, the default value for V8Compatible is false in 9i and 10g. This
means that by default the drivers incorrectly map SQL DATEs to java.sql.Date.
In 11.1 the default value of mapDateToTimestamp is true which means that by
default the drivers will correctly map SQL DATEs to java.sql.Timestamp
retaining the time information. Any customer that is currently setting
V8Compatible = true in order to get the DATE to Timestamp mapping will get
that behavior by default in 11.1. Any customer that wants the incorrect but
10g compatible DATE to java.sql.Date mapping can get that by setting
mapDateToTimestamp = false in 11.1.
About the only way to see the difference between mapDateToTimestamp settings
is to call getObject on a DATE column. If mapDateToTimestamp is true, the
default setting, the result will be a java.sql.Timestamp. If
mapDateToTimestamp is false, then getObject on a DATE column will return a
java.sql.Date.
HTH
Edited by: vasan_kps on Jun 12, 2009 2:01 PM

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

JDBC 10.1.0.2.0 bug

Similar Messages

Maybe you are looking for