This question already has answers here:
Is there a reason for never closing a JDBC connection?
(3 answers)
Closed 8 years ago.
a question just came to my mind when I noticed that I didn't close the connection to the database in many classes of my java application.
I wonder if this can affect my entire OS as the time goes by.
Thanks in advance.
To the Database, no. Depending on the driver and adaptor for your language, it will either automatically close itself after the request is complete or (most likely) just timeout after a while. It will continue to listen for your application's connection after the application has completed it's requests thus consuming more resources on the server until the DB decides it's time to end that connection.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I built up my server for my app which is running on Android. And i will hear some opinions from you if the setup is acceptable or complete wrong. So the architecture works like request-respone.
The user will log-in, every app start and will get a new session id.
The client and the server does not have a keep-alive connection. The connection is getting cut every request. For every command on the server, the session id need to get checked first, and then the command or request can be calculated. After everything is done the connection will cut. I was thinking about something that the connection will be held to the server and this gives me the possibility to send from the server some data directly to the client. This could have many usages. But on the other hand its not thread "able". Because i will have to synchronize the socket access and share 1 socket object between all classes and activity, this isnt in my opinion a good way. But am still wondering how other apps or online games could sent data or messages directly to the client. This means that a connection is held. I think that they doing it seperated in a service or something like this. This a new problem im facing. I could use firebase cloud messaging, but this is very slow when more as 100 threads are running on the server. A better solution where, to code a second server program, which is running seprated from the main server and keeps a connection to the client. This would be my solution.
What i just want to know if my architecture is good to go or its a bad idea.
In my opinion, opening and closing the connection is a good practice, because the connection is relatively an expensive resource.
So, I would say that yes, you're good to go with the architecture that you currently have implemented.
Open connection
Execute operation
Close connection
This question already has answers here:
How to increase number of threads in tomcat thread pool?
(3 answers)
Closed 6 years ago.
I am working on spring project. I put Thread.sleep(60000) on one api to check thread safety. If I call that api then all other apis wait for that time. I thought every api request processed by separate threads. So what is the reason behind this behaviour?
Issue resolved when I set maxThreads in tomcat server.xml file.
Thank you all for helping me resolve this issue.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a standalone application (no application/web server) with various methods accessing a database via JDBC. So far, a database connection is opened (and closed) in every method. There is no need for multiple connections at the same time.
But:
Creating a new connection every time seems a bad idea because of performance
Alternatively, using a single connection seems a bad idea as well.
What is the way to go? Connection pooling for just one connection?
If you configure it right, you can gain a lot by using a connection pool, most of all the performance of individual statements - connecting to the DB might be measured in seconds.
At the same time except for the initial pool creation (you might be able to run that parallel to other initialization) you still maintain a very good relaibility - as the pool will check connections on checkout or in between and discard connections that broke down. So you're likely to survive episodes of "not-connected" or similar as well.
I share your view that using a single connection might be a bad idea - because you'd have to deal with connection loss / reconnect all over your code.
A couple of benefits you could get from connection pooling, even if you only have 1 connection:
A connection pool typically manages the life cycle of it's connections. For instance, if a connection goes stale, a new one will be created in it's place. That prevents you from having to handle life cycle events in your code.
A connection pool can control the opening and closing of connections. Just because you call close() on a connection, doesn't necessarily mean the connection is closed by the pool. It can choose to keep the connection open. This can offer performance benefits if your application is constantly opening and closing connections.
Do not use connection pooling for only one thread.
For a standard JDBC connection pool, a pool of Connection objects is created at the time the application starts. That is when the connection pool server starts, it creates a predetermined number of Connection objects. These objects are then used by a pool manager which disperses them when they are requested by different clients. And returns them to the pool when the client doesn't need that Connection object. A great deal of resources are involved in managing this.
So it's basically wasting a little performance wise bothways if only one connection is being used throughout. IMO, opening and closing individual Connection objects will be a better option. Try sending batch queries to compensate on the performance loss.
This question already has answers here:
Best Way to Gracefully Shutdown a Java Command Line Program
(7 answers)
Closed 8 years ago.
Assume I have a daemon-style Java program (one that repeatedly executes a code block forever until terminated). I have code in it to periodically check for the presence of a file, and if present, delete the file and gracefully shut the program down.
To shut down the program, rather than killing its process, I would simply touch the file and wait for the program to shut down (and for the file to disappear).
Is this a good practice or bad practice? What are the reasons?
What other ways can the graceful shut down of a Java program be implemented?
Note: I already saw this question, however none of the answers satisfy the questions above.
What if the process crashes? Now the file exists and the program will never start up again?
I've seen this mechanism used before, and that's always a weak point.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a small client server app , that involves the client pinging the server on a set of ports ( 90,6100,6200).
I use inet.isReachable(30000) to monitor whether the server responds to the client or not.
In the end , I want to make sure that when I re-run my application , any existing connections to these ports are removed.
How do I go about doing so ?
And is there a way to automatically close a connection when I am using InetAddress, which does not seem to have any method to terminate an existing connection to an address ?
"I want to make sure that when I re-run my application , any existing connections to these ports are removed."
The connections cannot stay open when your application exits - there is no process for them to be connected to. So in that sense, you don't have to worry about closing them on next launch.
"And is there a way to automatically close a connection when I am using InetAddress, which does not seem to have any method to terminate an existing connection to an address ?"
Yes - the connection will close when isReachable is responded to, or when the timeout expires (or some other error occurs). Just creating an InetAddress does not create a connection - it automatically creates and destroys them as needed to do its functionality. Connections are generally just short lived things that don't stay open unless you make them.
The JVM will close the connection after the server responds to isReachable or the timeout expires, whichever comes first.
The answer to your vague question is that as connections don't survive the process they are created by, and as INetAddress"isReachable() doesn't leak connections, there is no actual problem here to solve.