We are running SQL Developer 3.1 on Windows 7 64 and connecting to a 11.2.0.3 database.

The user's can connect fine, then they can click through and see their tables. Once they click on the tables to see the columns or data, we immediately get disconnected.

We have 1 user still using SQL Developer 2.x and seems to have no problems. We were using 3.0 and couldn't get past connecting. We would click to see a list of the user's tables and would get disconnected then. Now by moving to 3.1 we at least can listing of the views, tables, etc but once we try to click deeper, we get the disconnect.

Thanks, we will look into that. It does seem to only affect the non DBA users. If I log in as SYS user as SYSDBa I don't notice it. I'll test it will another user as SYSDBA and see if any problems encountered.

What is odd to me is that the 2.x version seems unaffected and there were differences in what was affected betwee 3.0 and 3.1 SQL Developer. Plus, everything worked fine till about 24 hrs and we started having random connect issues with outside connections. We weren't sure if the 2 were related since 1 seems random and the SQL Developer problem can be easily replicated and produced.

We are using JDK 6.31 64 bit along with the 64b version of SQL Developer if that helps any with the debugging

The temp solution that Gary Graham provided, worked in the short term. What ultimately fixed it for us was switching the DB to DEDICATED from SHARED. Once that was done we were able to remove the temp fix, restart Developer and worked as good as new. It also fixed out other random connect problems with outside connections to our DB.

What ultimately fixed it for us was switching the DB to DEDICATED from SHARED.

A close read of the full thread I referenced above (both in John's comments and the comments of others) does point to the use of shared connections as a risk factor in triggering this low-level TCP bug. Actually even if the DB is configured for shared connections, a user relying on the SQL Developer connection type=TNS (as opposed to, say, Basic), could override the shared connection usage by specifying SERVER=DEDICATED in his tnsnames.ora file.

Some other comments...
1. Out of Band break support in JDBC began with the drivers shipped with Oracle 11g (ojdbc5.jar for 11.1.0.6, ojdbc6.jar for 11.2.0.2).
2. SQL Developer 2.1 ships with ojdbc5.jar, whereas the 3.x releases ship with ojdbc6.jar. These jars are used if no Oracle client is present.
3. If the Oracle client's ORACLE_HOME jdbc\lib contains both ojdbc5 and ojdbc6, a 3.x install may incorrectly use ojdbc5.
4. Out of Band break failures are more common on Windows platforms.
5. Out of Band break failures are more common, per the forum posts and bugs I have reviewed, when using ojdbc6.

Presumably there are timing issues when the ratio of connections to shared server processes is too high. If use of DEDICATED is not feasible, possibly lowering that ratio may help.

It was the comments from that thread that pointed us in the direction of looking at Shared as part of this problem as well as the overlaying problem of the other connections. So it helped us not only here with Developer but with our overall problem.