I recently saw a post in which it was described to close buffered reader or connections. What is the importance of closing these connections & what overhead will occur if we don't close these connections? Regards.
if you not closing the connection ,then for every user the connection will create .. remember there is a limited number of connection only . so for the next user he wont get the connection to DataBase . ----------------------------------- you should close the connection properly -----------------------------------
Joined: Oct 06, 2008
what will happen if we don't close the streams? Is there any connection limitations on streams also? If yes how can we find the limit? Regards.
There is a limit, but I don't know what it is. It may vary from computer to computer. Try opening lots of file connections as Readers and see how many you can open and not close before you start getting exceptions.
The OS will close dead connections automatically, but it could take some time (relative to how fast operations should happen on a computer). A good example, though not with files (same concept though), is ports. Use a socket to connect to a port on your own computer, don't close the connection but exit the program. Immediately re-run the program and you'll sometimes get an IOException because the socket is still blocked.
The same applies to files, it's just that there can be multiple processes accessing a file at once. There is a limit though.
Originally posted by Chris Blades: but exit the program.
True, if you exit the program all (file) handles will eventually be released. The thing is, you will more likely run into problems if you don't exit the program, and keep running. Especially on servers this happens a lot. The OS doesn't know you don't need the handle any more so it keeps it open.
Also here, eventually the garbage collector will collect your objects, and if the finalize method is written correctly the handle will be released, but everybody should know that you can never predict when it runs. In fact, I once had a semi-realtime system setup that was so swamped that it crashed with a memory error. Because all other threads had a higher priority (realtime, remember) the GC never even ran.