Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

This issue below might be an application problem, but I cannot seem to rule out a poor database setup, I was hoping to get some insights into potential database issues.

I am maintaining a legacy Java application, our hosting provider provides DBA support for our Oracle database. We were on 10g, several months ago we upgraded to 11g. I in turn upgraded the Java drivers from ojdbc5.jar to ojdbc6.jar. Everything mostly seems fine....

The application uses Hibernate ORM tool, one of the fields of this one entity happens to be a Blob type. When the application saves changes to this entity, the generated SQL is an update statement that includes this Blob column regardless if it has changed or not.

On this one operation, the user updates their annual subscription, so they do it once a year, but when it calls the update here Java throws "Unable to access blob stream!" and then claims the underlying connection is closed. This ONLY occurs for this one operation.

If I completely shut down and restart the server, and then perform the same operation again it works perfectly fine and continues to work fine for that one record forever and ever amen.

But it seems to happen here for every single record in this one table at least once.

Needless to say this is a nightmare to debug because I cannot reproduce it on a single record, just observe it once per record on my test system, then never see it happen again, and yes the same behavior occurs on my test environment that is a mirror of my production database.

My question is if it is possible that when the Oracle 11g upgrade occurred that it corrupted the LOB space in some way to where this seems to be happening?

EDIT:

Now I can't reproduce it on any record.... its like the database felt that I was trying to debug it and temporarily reverted into a state of good behavior

Maybe the LOB space was sleeping, then woke up?

EDIT 2:

The problem happened again this morning, after I left the database to sit unused for several hours.

As requested here is the exact error:

Unable to access blob stream! Cause: Closed Connection SQL State: 08003 Vendor Code: 17008

Preliminary research seems to suggest that this might be an issue with the Oracle JDBC drivers? Oracle JDBC 11.2.0.3 ojdbc6.jar

share|improve this question
    
Without any specific error messages and the fact that you now can't reproduce the problem, this needs closing. –  FreshPhilOfSO Nov 5 '12 at 22:29
2  
I also love the fact you see that Oracle has feelings. xx –  FreshPhilOfSO Nov 5 '12 at 23:47
1  
@Phil I added the exact error message because after leaving the DB sit for several hours unused it happened again. I don't believe it a connection pooling issue because I just started the test server up this morning. –  maple_shaft Nov 6 '12 at 13:00
    
Please dig through database-server-side errors. Check alert*.log and the recent *.trc files. –  kubanczyk Nov 9 '12 at 14:44
    
Check the version of your driver. The 6 in ojdbc6.jar does not indicate the driver's version. There are about 10 different versions all named ojdbc6.jar. The version can be checked by looking at the MANIFEST.MF which is stored inside the jar file. –  a_horse_with_no_name Nov 25 '12 at 22:23
show 3 more comments

1 Answer

I have faced similar situation for a procedure call with input Blob parameter. Same piece of code was working just fine on 11.2.0.2, but began to throw "java.io.IOException: I/O Exception: Connection reset by peer: socket write error" on 11.2.0.3. I have downgraded from ojdbc6.jar to ojdbc14.jar+ocrs12.jar now it is working. I don't know why but it seems ok for now.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.