Win a copy of Spark in Action this week in the Open Source Projects forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Static connection variable

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question I have is relatively simple, but being slightly new at Java, its confusing to find the right answer:
In the case of an extremely simple single user standalone java application, are static connection variables still considered bad practice?



For example, using the Connection variable C in the above DB class to connect to the database across the application.

Another small question I have is,
Again in the case of a simple, single user application, will keeping the connection open (instead of closing DB.closeConnection()) have any undesirable consequences?

Many thanks
 
Saloon Keeper
Posts: 12126
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Static variables are always a bad thing. Don't use them. Only use static fields for constants.

Keeping connections open has the undesirable consequence that if you create many connections, you may run out and the program may fail.

It's just good practice to get into the habit of using proper connection pools, and disposing your connections as soon as you don't need them any more.
 
Marshal
Posts: 25669
69
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
+1 for what Stephan said. In addition: as soon as your simple application finds that it needs to have two connections open at the same time (for example if you need to execute a second query before you've finished processing the first query) then your static-variable design is broken. You might then react by trying to modify that to have a static collection of connections, but again what Stephan said, it would be better to just use a connection pool. This has two advantages: (1) Somebody already wrote the code, and (2) It works already.

Another issue with your code (and maybe it's a shortened version just for an example to use here, I don't know): It doesn't use or even support PreparedStatement. It doesn't take long before a simple application finds the need to insert variables into a standard SQL query. You could write your own string-bashing code to do that, but you'll struggle with getting the quotes right, especially when you have to escape quotes in character fields. As your simple application expands you'll find that encapsulating standard-looking SQL code becomes more and more annoying to maintain. In other words the whole idea of a "DB" class which tries to encapsulate "DB" operations is rather suspect.
 
Paul Clapham
Marshal
Posts: 25669
69
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And. welcome to the Ranch!
 
Rancher
Posts: 4603
47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing that connection pools handle, which a lot of people "rolling their own" forget, is connection timeouts.

Databases often close connections that haven't been used for 'x' minutes, meaning the Connection object will throw an error when it's used.
 
    Bookmark Topic Watch Topic
  • New Topic