How do you switch ADO to be BOTH? In the reg?

-----Original Message-----
From: Steve Swartz [mailto:steveswMICROSOFT.COM]
Sent: Wednesday, November 28, 2001 7:13 PM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: VStudio Magazine Oct Article

Yet another problem with this trick is that ADO is, by default,
configured to run in the STA. So all of the threads trying to use the
single component would be serialized on access to the thread on which
the ADO component happened to be created. You can manually switch the
ADO component over to "BOTH" (and that's a good idea if you're running a
lot of C++ code against ADO), but that wouldn't help in the VB/ASP
environment the author is talking about. Marking ADO to run in the MTA
would be a problem in a VB/ASP environment.

-----Original Message-----
From: Steve Swartz
Sent: Wednesday, November 28, 2001 4:04 PM
To: Steve Swartz; 'Distributed COM-Based Code'
Subject: RE: Re: VStudio Magazine Oct Article

Another thing that might be surprising to someone using this trick is,
the ADO recordset is created in the "original" context. If you use this
trick in an MTS/COM+ application, you'd never get auto-enlistment (the
ADO component would not see the caller's context).

-----Original Message-----
From: Steve Swartz
Sent: Wednesday, November 28, 2001 3:14 PM
To: 'Distributed COM-Based Code'
Subject: RE: Re: VStudio Magazine Oct Article

I'm confused by several aspects of this article.

First, if two threads use the same ADO connection and start two
transactions, the second transaction would be nested inside the first
one. Most users of ADO in scalable applications need to write to the
database and hence need to use transactions. It seems to be an oversight
that transactions are not mentioned in this article.

Second, while execute methods themselves are stateless, if a call into
ADO returns a recordset, all other threads using the ADO connection will
block until the first thread read the recordset. This would have
scalability impacts not mentioned in the article.

Third, the author speaks of "MTS's object pooling technology" on page
three of the online version of the article. Object pooling does not
arrive until COM+ and Windows 2000. The article also mention using this
trick within MTS and COM+. An ADO component cannot be used inside of two
transactional contexts at once.

It seems to me that a pooled COM+ component containing an ADO connection
is probably as close to the author's intent as it is possible to get in
the general case. This minimizes the number of ADO connections held
within a process, yet makes sure that every client that needs a separate
ADO connection gets one.

-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOMDISCUSS.MICROSOFT.COM]On
Behalf Of Robert Sedor
Sent: 28 November 2001 17:58
To: DCOMDISCUSS.MICROSOFT.COM
Subject: VStudio Magazine Oct Article

In this issue, there is an article by Dimitrios Tsonis titled, "Enhance
Performance With ADO Connection Object".

Basically, he creates a global connection and then hands it out to
everyone. That is he hands out a reference to the same connection to
every
client.

http://www.devx.com/premier/mgznarch/vbpj/2001/10oct01/dtf0110/dtf0110-1
.asp

He states that this is faster than Microsofts connection pooling
mechanism
and scales better.

It is all written in VB using ADO.

Someone please read this and tell me it isn't so.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]