After seeing a Connection Closed log message, did you reconnect your VPN client prior to trying to reconnect a SQL Developer connection?
Starting back in SQL Developer 3.2 production, before enabling the Reconnect context menu item, the product verifies (with a brief, 2 second time-out limit) the database listener the connection points at is reachable over the network and listening for connection attempts. If that test times out, then the Reconnect item is not enabled. Perhaps the 2 second limit is too short in some environments and should be configurable via a Preference? Otherwise it should work fine, and works for me on 4.0EA1 and 4.0EA2.
SQL Developer Team
when I saw the message, the connection was not broken.I 'd conjecture that there are occasional glitches in my (adsl) connection. The VPN somehow generally survives, and so do my windows shares and outlook connection, but OCI/sqlplus, sqldev (*not* over OCI) or occasonial ssh connections get broken.
Now, if i start sqldev 3.1 with the "keepconnected" extension and configure it to ping the server every 13' (for example), my db connection almost always remains up (even if left alone for a couple hours). If I start 4EA2 and leave it alone similarly, I am pretty much certain to find it broken when I come back, I have also noticed that the "keepconnected" or "keepalive" extensions do not seem to work with sqldev4 anymore, so some API has probably become incompatible, leaving these unusable.
Having to reconnect would be viable if at least the option to do so knew what the worksheet seems to have realised - that the connection was indeed lost. Ideally I'd prefer a keep-alive option being included in the connection properties but I remember reading a Jeff Smith' blog post as to why this wouldn't happen - dba's wouldn't want it (sorry I could not find the link back).
Sorry to sound like a broken record, as I think I have been complaining about this very issue since at least 3.0EA's. Thanks for trying to help with the "reconnect" feature, but so far it has never actually worked for me. I can just a s well "close" the broken connection without closing the associated worksheet, then reconnect (which I find cumbersome).
Short story: "reconnect" does not seem to work any better in 4EA2, and extensions that use to alleviate the problem are not working with it either...
1 person found this helpful
So it seems your best bet would be to contact the third-party developer of the Keep Alive Extension and encourage him to upgrade it to conform to the OSGi specification now required by SQL Developer 4.0 (inherited from our JDeveloper framework): Introduction to Developing Oracle JDeveloper Extensions
With regard to your comment The VPN somehow generally survives, I can only say that when my VPN client loses its connection, the warning dialog gives a message to the effect that the automatic reconnect feature has been disabled -- manual reconnect required. Perhaps Oracle IT configures it that way to help its employees avoid the sort of issue you are experiencing?
In terms of testing SQL Developer's reconnect feature, as I recall, at least the following scenarios have been tested:
- Physically unplug the client machine from the network on which a remote Oracle server resides
- Kill the client session on the Oracle server
- Suspend/Resume a VM running the Oracle server
- Cycle the client machine through states of sleep or hibernation
- Click the Disconnect button in the VPN client
Possibly a future version of SQL Developer will have an improved reconnect, but your predicament may be an edge case that is difficult to handle.
Thanks Gary for your replies and I can imagine this is not the most demanded or easiest to test feature. The facts remain, though, that
- something is plainly unintuitive in the worksheet "realising" that a connection is dead, yet the left-hand side connection node not knowing so (hence not offering the reconnect option), couldn't these be synced?
- I did not seem to have that kind of problem with toad (a couple years back when I still had a licensed copy, perhaps it was pinging behind the scene?)
- breaking extensions gratuitously does not sound like the best way to keep contributors interested in the ecosystem
something is plainly unintuitive in the worksheet "realising" that a connection is dead, yet the left-hand side connection node not knowing so (hence not offering the reconnect option), couldn't these be synced?
I will look into this -- I believe there are also instances where the Reconnect is enabled even when it should not.
breaking extensions gratuitously does not sound like the best way to keep contributors interested in the ecosystem
This is not gratuitous, just a case of having to break eggs to make omelettes. Technology marches on (and keeps programmers employed).
> I will look into this -- I believe there are also instances where the Reconnect is enabled even when it should not.
Now that you mention it, I think I've seen it available too, for a working connection (no idea how to reproduce this, unfortunately).
Enjoy your omelette ;-)
Not sure if anything is supposed to have changed with 4EA3, but I am still seeing dead sessions without the left-hand connection node realising nor offering the "reconnect" option.
Well, not for 4EA3, but it seems you are in luck for 4.0 production. A decision was made to always offer / enable the Reconnect option. It does look a little strange in the context menu when the connection is either ...
1. Not open yet, or
2. Open and alive
however clicking on Reconnect is those cases does nothing, so no harm in having it there.
Hope this change helps you,