We Keep Coding

Providing connection time out in Derby client driver

I have a requirement that retrieving a connection times out within specified time from the connection pool if there is any problem in the network. This should be handled through a java application.
Basically, want to give timeout to datasource.getConnection() method.
So after some research, I found setLoginTimeout(int seconds) method of DataSource has this functionality in order to notify if a database connection can not be made within the specified seconds.
I applied this on OracleConnectionPoolDataSource which is working fine, but for the Derby client driver it's giving exception as,
org.apache.derby.jdbc.ClientDriver does not have any such attribute loginTimeout.
Looking for your kind responses, please do let me know if there any other way to achieve this as per my requirement or anything I need to add/missing or any information related to this.
Server - Resin 3.0

finally able to achieve this by using c3p0 connection pooling instead of using datasource for derby.C3P0 has checkoutTimeout property which exactly works as per this requirement.

Can I change the 'appName' on an already open JTDS connection?

I'm looking for a way to pass web-application transaction information on to the underlying database process. In my Java code I might have a transactional method ReservationService#search(), which runs one or several SQLs. On the DBMS I just see a SPID along with some locks. I'm looking for a way to add a tag "ReservationService#search" to the database process.
jTDS / Sybase ASE have an appName which can be passed in as a connection property. As we're using a connection pool, existing connections are re-used, but to my knowledge the appName is only read on establishing a new connection.
How can I re-set the appName on an already existing connection (without closing/opening)? Or, if that simply is impossible, are there any other ideas to get transactional context information from Java to the DBMS?
Tomcat Webapplication (Java 6)
C3P0 Connection Pool (only supports JDBC 3)
jTDS connecting to Sybase ASE 15
Thanks
Simon

Unfortunately not, it seems that you can only specify that in the URL parameters when you open up the connection but can't be altered afterwords.
You can aways pass in a SessionID of some kind from your Java/Tomecat to all your Sybase queries. For me, this was easy as I use stored procedures for all communications between my Java application and the SQL server. I based my SessionID in Java on the J2EE session.

SQLException: Protocol violation. Oracle JDBC Driver issue

I'm getting the following excpetion:
java.sql.SQLException: Protocol violation
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:145)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:190)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:286)
at oracle.jdbc.driver.T4C80all.receive(T4C80all.java:766)
at oracle.jdbc.driver.T4CPreparedStatement.do0all8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.fetch(T4CPreparedStatement.java:1225)
at oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:373)
at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:284)
The Oracle system is running 10.2.0.3.0 on Solaris 5.10. The jdbc driver is running on JDK 1.6.0_21 (if it's import the java is running on a Solaris 5.10 machine as well). I've tried several different oracle thin drivers including the latest and the one that appears to exactly match the oracle version.
The query I'm running is fairly simple: "select * from some_table order by key1, key2, key3" Then iterating through the result set and writing to a file. The table has around 12 million rows, so I expect the process is running long, but it seems to die within 5-15 mins into it. Each time I run it, it blows up on a different row, so I don't think the problem is with the data.
I found the oracle alert log but I couldn't tell that anything in there was related to my process. Still, I'm no oracle expert and perhaps there's an oracle setting I need to look at. Strangely enough, I'm running about five of these type of queries (a couple are a bit more complicated) on different connections and only two simplest ones ever get this problem.
Any help or ideas on what to look at to narrow down the problem would be appreciated.

For future googlers who are have to this page, here is the problem we had .
The protocol violation exception was being logged on application logs and Oracle trace.
Oracle trace
This is error from oracle trace files
--- PROTOCOL VIOLATION DETECTED ---
----- Dump Cursor sql_id=1j5kjnkncpp xsc=0x2a053a2a0 cur=0x2a052f1cf0 ---
----- Current SQL Statement for this session (sql_id=1jjns4k6npp) -----
select xyz
From Application Logs
Caused by: org.springframework.jdbc.UncategorizedSQLException: SqlMapClient operation; uncategorized SQLException for SQL []; SQL state [72000]; error code [20000];
Symptom
This exception was happening occasionally. The stack trace had different sql in it which was very confusing. Running the sql with sql plus worked fine.
Root Cause
The exception was thrown when oracle driver was trying to export a CLOB data. This was happening with only few records, not all of them. The data as such was a file. Visually we could not make out what was wrong with that data.
Why we were seeing errors in oracle logs ?
So if this was a driver defect, why did we see the error in oracle trace ? Logically the driver errors should be only confined to application logs.
The reasons was that when protocol violation happened, the connection got corrupted. This connection was returned to the connection pool. Any user or job when will use that connection would not work and would experience error.
That is why it will happen at random places, with random users
Solution
A short term fix was to change this property in connection pool. We are using DBCP connection pool.
Changed from
ds.setTestOnBorrow(false);
to
ds.setTestOnBorrow(true);
Now when the pool returns a corrupted connection to the pool, before app borrows this connection , it would test for validity. If connection is unusable, pool would discard and then app gets a new/valid connection.
If you enable connection pool logs, you should see the exception which normally is swallowed.
Driver Upgrade
Upgrade to OJDBC 12.1.0.2 from OJDBC 12.1.0.1 solved the problem, even for the problematic rows.
Some other links for reference
https://confluence.atlassian.com/display/CONFKB/java.sql.SQLException%3A+Protocol+violation+caught+while+accessing+a+page+and+Oracle+DB+is+used

Apparently adding -d64 to the java command line fixes this problem. Looks like a Solaris 64-bit issue.

In my case, using tomcat 8.5 (standard connection pool), oracle 19, when oracle emits an warning message (like 'your password will expire in n days'), the java connection object interprets like an error.
I just change the PASSWORD, by the same name, and the problem was solved.

JavaDB connection issues; database not found

I am having a problem with Java DB that I just don't know how to resolve. I am creating a DB and connecting to it using Java DB's native JDBC driver. If I relocate that database physically and try to connect to it using its new path, I consistently get XJ004 errors:
ERROR XJ004: Database 'blahblah' not found.
I am sure I am using the correct connection string. Is there any possibility the DB is somehow getting corrupted? Or is there some encoding of the DB path in the DB such that if you relocate a Java DB it gets confused?
I'm really at a loss here. :( Please help!
Jim

Have you verified that this error message isn't also used when there's no listener on the host machine ... and were you using JavaDB on your local machine before the relocation? Many database systems (and I'm not that familiar with JavaDB) ship set-up to only allow connections from localhost for security reasons. On PostgreSQL for instance, you have to allow TCP connections and bounce the daemon to obtain a remote connection.
Anyway ... since the problem started when you when remote, look for issues related to that first! (And if you can run your application on the remote machine, does that work?)

There must be a file named derby.log somewhere. Check the error there. If it is not detailed enough, try setting derby.stream.error.logSeverityLevel to a lower value. See the manual for more information.

How to handle: Communication link failure

We're using Spring 2.5.4/Hibernate 3.2/Websphere Application Server 6.1.0.17. We've deployed the application on an AIX box. The next day when I come in, I try to log into the application. I get this exception on the page:
Error 500: Request processing failed; nested exception is org.springframework.dao.DataAccessResourceFailureException: could not execute query; nested exception is org.hibernate.exception.JDBCConnectionException: could not execute query
I checked the System.Out logs and see further details. (Used pastebin because the log formatting was really screwing up the page layout)
The line of our code that is causing our exception is:
List loginList = getHibernateTemplate().find("from Login
where storeId =" + id + " and password ='" + password + "'");
We are wiring the connection in Spring's applicationContext.xml. We are aware that the connection on the AS400 drops at times (they may restart the system overnight--I'm not sure). However, we would preferably not want to open a new connection when we are wiring everything in the applicationContext.
This problem occurs irregardless of using a DataSource/JNDI or JDBC
Does anybody know of any settings to add to either Spring or Hibernate to check if the connection gets stale, and if so, drop it and create a new one? Or any other ideas to resolve this issue? Let me know if you need more information/code.
Much appreciated,
Chris
Update:
Checked out some posts on the Spring Community Forums and I've implemented my DataSource with commons-dbcp which has some properties like 'testWhileIdle' and 'validationQuery'. I'm going to leave the app running and check it again in the AM. Will post an update on the results.
Update#2:
Using dbcp-commons BasicDataSource seems to correct this issue, which appears to be a network problem. Websphere has pooled connections, and if there's a network issue on the AS400 side, it will try to use the connection it has, which it doesn't know is 'stale'. Using a validationQuery with a time interval is a cheap (but efficient) way to solve this problem--but there may be a better way on the Websphere side, under configuration. But, might as well not change what's not broken, so until this fails, it will probably be our solution going forward.

Ah, that's what I was gonna say... the problem must be solved in the connection pool, by validating connections before returning them. DBCP has validationQuery, and JBoss also has something similar; I'm sure Websphere must have something similar in its connection pool to validate connections before handing them out. Even if you don't use testWhileIdle, if the connection is found to be invalid, a new one is created and handed to you by the pool instead of the invalid one.