Jump to content

SQL Connections - Persistent or as needed?

- - - - -

  • Please log in to reply
5 replies to this topic

#1
Timinator

Timinator

    Newbie

  • Members
  • Pip
  • 6 posts
I'm currently developing my first Java desktop application using MSSQL as a back end. I've initially designed the app to have a database object which would allow me to pass my sql statements to the object and then have the object send the resultset back. However, it seems that the calling object has to carry the overhead of the try/catch code just to call the database object.

So, my question is, should I just be opening and using my database only when needed and code for each occurrence where it is needed? Or am I heading down the right path of opening my database at the start of app load and pass sql/resultsets to my database object?

Thx.

#2
Alexander

Alexander

    It's Science!

  • Moderators
  • 4,118 posts
  • Location:Vancouver, Eh! Cleverness: 200
Certain databases have limited number of maximum connections, in a web environment a persistent connection is very limiting. In your case of a desktop application, and MSSQL being slow at connections as needed a persistant connection can be advantageous if you are using it in a constant manner.

If you are just utilizing a database on-load and on-save (occasionally) then you can consider if you would be advantageous or not.
Be sure to read the updated FAQ! || Health is achieved through the same 10,000 steps.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.

#3
WingedPanther

WingedPanther

    A spammer's worst nightmare

  • Moderators
  • 16,831 posts
  • Location:Upstate, South Carolina
  • Programming Language:C, C++, PL/SQL, Delphi/Object Pascal, Pascal, Transact-SQL, Others
  • Learning:Java, C#, PHP, JavaScript, Lisp, Fortran, Haskell, Others
I do almost all of my database work in Delphi, not Java. With that said, for database heavy applications it's usually worthwhile to have a single, persistent database connection object, and queries that use it as needed. Error trapping is generally done in the code that has the query, since that is where you can actually interpret the significance and nature of the error, and react accordingly.

SQL queries can throw a lot of errors that range from "you completely hosed up this statement, programmer", to "yeah, it should have worked, but somebody else beat you to this primary key".
Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

#4
Timinator

Timinator

    Newbie

  • Members
  • Pip
  • 6 posts
Delphi is pretty cool. I'm an old Turbo Pascal hack from way back. However, I'm doing this to make myself more marketable. Looks like I'll go with the persistent connection. Plus, I like being able to write all my error traps in one spot.

Thanks for the feedback.

#5
WingedPanther

WingedPanther

    A spammer's worst nightmare

  • Moderators
  • 16,831 posts
  • Location:Upstate, South Carolina
  • Programming Language:C, C++, PL/SQL, Delphi/Object Pascal, Pascal, Transact-SQL, Others
  • Learning:Java, C#, PHP, JavaScript, Lisp, Fortran, Haskell, Others
I usually put my error traps around where I'm handling individual queries (either making the query or processing the record set). It's easier to control detailed error messages that way :)
Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

#6
sam_l

sam_l

    Learning Programmer

  • Members
  • PipPipPip
  • 52 posts
Due to the large resource cost associated with database connections I would use the singleton pattern, especially if you only need a single connection to a single database. This should minimize resource usage and allow for easy use.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users