Connection object versus Connection String

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!
***************************

William
Thu Sep 30 15:03:07 CDT 2004

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.
__________________________________

"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote
in message news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
> 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!
> ***************************

Mythran
Thu Sep 30 15:20:28 CDT 2004

Hrm, wondering if the System.Configuration namespace would come in handy to pull
the Connection String from the application's configuration file <appSettings>.

Mythran

"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
message news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
> 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!
> ***************************

Sahil
Thu Sep 30 16:35:08 CDT 2004

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


"William (Bill) Vaughn" <billvaRemoveThis@nwlink.com> wrote in message
news:uN5xBiypEHA.3800@TK2MSFTNGP14.phx.gbl...
> 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.
> __________________________________
>
> "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM>
wrote
> in message news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
> > 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!
> > ***************************
>
>

Cowboy
Fri Oct 08 13:55:13 CDT 2004

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!
*************************************************
"William (Bill) Vaughn" <billvaRemoveThis@nwlink.com> wrote in message
news:uN5xBiypEHA.3800@TK2MSFTNGP14.phx.gbl...
> 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.
> __________________________________
>
> "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM>
> wrote in message
> news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
>> 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!
>> ***************************
>
>

Cowboy
Fri Oct 08 13:56:41 CDT 2004

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!
*************************************************
"Mythran" <kip_potter@hotmail.com> wrote in message
news:%231jYurypEHA.3068@TK2MSFTNGP15.phx.gbl...
> Hrm, wondering if the System.Configuration namespace would come in handy
> to pull
> the Connection String from the application's configuration file
> <appSettings>.
>
> Mythran
>
> "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM>
> wrote in
> message news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
>> 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!
>> ***************************
>
>

Cowboy
Fri Oct 08 14:03:25 CDT 2004

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!
*************************************************
"Sahil Malik" <contactmethrumyblog@nospam.com> wrote in message
news:%23UMJNVzpEHA.2864@TK2MSFTNGP12.phx.gbl...
> 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
>
>
> "William (Bill) Vaughn" <billvaRemoveThis@nwlink.com> wrote in message
> news:uN5xBiypEHA.3800@TK2MSFTNGP14.phx.gbl...
>> 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.
>> __________________________________
>>
>> "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM>
> wrote
>> in message news:69F9A89C-8EC2-495B-B551-893774DA5E27@microsoft.com...
>> > 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!
>> > ***************************
>>
>>
>
>