how do you differentiate between a shared and a dedicated connection? If I only have one connection, and am trying to open the tables item in the navigator, with no other window open, doesn't that count as a dedicated connection?
Thanks for the info, K, but I don't think so. I spoke with the local DBA, who claims "nothing has changed!!!". In any event, when I downgraded from 3.0.04.34 to 18.104.22.168, I am now able to see the tables again. With the later version, I am still not able to see them.
I think what is meant here, is whether your connection is using a shared or dedicated server process. Has to do with how the server is managing your connection, not how many connections you have at your client. I recently switched my DB to only use dedicated server processes while troubleshooting another issue and this problem I had swith SqlDev immediately went away. Here's some Oracle verbage on it:
The same problem not exist on Linux (Fedora ). Sql Developer work fine even with shared connections.
I have see the difference is the level of JDK. (Because the jdk is not provided on linux)
I put the last JDK on windows but i got the problem again except when the connection is to 11G Database.
I believe I have identified what is causing these issues for some users and not others. It appears there is a bug in the JDBC driver having to do with 'Out Of Band Breaks' - basically a low level TCP issue. The bug seems to manifest itself in a number of ways. So far I've identified using shared connections (particularly with Vista or Windows 7) and connecting over VPN (any OS) as common scenarios. In all cases, not having DBA access is also an issue.
First, let me explain why DBA access makes a difference. When we first access any particular data dictionary view, we first try to see if we can get access to the DBA version of the view (or is some cases tab$, etc). These views are much more efficient than the ordinary USER versions, so we want to use them if we can. We only check each DBA view once per session (and only when needed), but we can end up checking for access to a bunch of views.
The OOB bug seems to rear its head when we do this check. We should get a nice, simple response back from the database. However, in the scenarios where the bug is occurring, this low level network bug is instead causing an error to occur that puts the connection into an unusable state. This then results in all the Connection Closed errors.
There does appear to be a workaround - the JDBC driver supports disabling OOB. However, doing so will affect the ability to cancel an executing statement, So I wouldn't recommend using the workaround in general, but it should solve the issue for the situations where users are running into this specific problem.
To enable the workaround, a Java system property needs to be set - oracle.net.disableOob=true. You can set this in two ways. The first is to pass it in on the command line as sqldeveloper -J-Doracle.net.disableOob=true. Of course, that only works if you are normally running from the command line. You can also add a line to the sqldeveloper.conf file (located under sqldeveloper\bin). There the line would be AddVMOption -Doracle.net.disableOob=true
We are looking into additional resolutions, but for now the workaround should enable you to work with SQL Developer.