Connection object versus Connection String

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

At work, we have built a Director object that fires off processes. Any number
of jobs can be run at the same time through its own Director instance.
Currently, there is a philosophical discussion about either passing in a
Connection String or a Connection object to the individual processes.

I am siding with Connection String, but do not have anything to support this
direction over the other. According to books, Connections are pulled from the
underlying pool with Open() and released with Close() rather than Object
instantiation and Dispose(), so you should still be able to pool with a set
of passed objects.

Is there anything I am missing that would swing the decision one way or
another?


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Consider that you can't pass a Connection object out of process. In
addition, until MARS it won't be possible to reuse a connection that's busy
handling another operation. It's far easier to pass the ConnectionString and
let the pooler do it's job. Of course, each process (application domain)
gets its own pool.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Hrm, wondering if the System.Configuration namespace would come in handy to pull
the Connection String from the application's configuration file <appSettings>.

Mythran
 
To add to Bill's point, The only advantage you get by passing objects
instead of string ---- ConnectionStrings occupy more memory than a pointer
reference, but still we are talking very little difference, so ignore that
argument if anyone brings it up. (The advantage is too thin).

But from future planning point of view, you know a string will pass any
object boundary/machine boundary/appdomain/unameit. It can be easily
persisted, stored in a config file, and it is ultimate portable even between
operating systems/over tcpip/mainframes, throw it inside a database, do
insanely wild activities with it, even build it dynamically based upon
something .. . Heck you can write it down on a peice of paper and make your
dog read it (if you tried hard enough). Try doing that with a connection
object (which is a living entity in memory) .. (is it serializable?).

Ok I'm rambling too much now .. LOL

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik
 
Thanks, Bill! I have been arguing for a connection string instead of
connection object since the beginning, but I am being vetoed.

According to the MSPress ADO.NET Core book, connections are pulled from the
pool on Open() and released back on Close(). As our process is linear, they
feel that the connection object being passed is okay, as the underlying
objects are being released to the pool (if someone has some white paper that
contradicts this being how the pool works, please send me an URL).

The out of process may be a selling point for the future. Currently,
however, the entire process is run from start to finish on one blade server,
so there is no "out of process" calls.

I did find one gotcha today, however. I had a string of objects. In the
first, I called Dispose() and killed the object. Old habits die hard?

I mentioned we need to code for that eventuality, to which I got the answer
"Before you make such a request, you should never dispose of the connection
object as it will be disposed of when the ### object is disposed of." My
request was to move back to connection strings.

I still believe conn strings are a better way to go.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
The main reason for having an object is to have an easy way of setting
hundreds of settings without the overhead of consulting the XML file. I am
not certain the overhead is that bad, but the object does give a means to
split this out over a few blades in the future (not with the conn object in
it, of course).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
Sahil:

I am, personally, against the connection object, but I am not the only one
with a say in this one.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
 
Back
Top