Python + IIS/ASP questions (modules, namespaces, etc)

[dsavitsk]

"Preston Landers" <pibble at yahoo.com> wrote in message
news:1136f745.0212181536.239a87cd at posting.google.com...
> "dsavitsk" <dsavitsk at e-coli.net> wrote in message
news:<W_4M9.2152$qU5.1302847 at newssrv26.news.prodigy.com>...
>
> >
> > My guess is that a single use COM server could keep track of the number
of
> > connections and start up a new server when some threshold is reached.  I
> > think this is the way to do it.
>
> This is actually not a bad idea -- however it is complicated by some
> details that I did not mention in my original posting.
>
> We had already thought of a solution like this, but we have inherited
> a fairly broken design for a caching layer in these application
> servers.
>
> Basically, each app server maintains a socket connection to *every
> other* app server for the sole purpose of sending brief "clear caches
> for table X" messages to each other.  That means the total number of
> interconnections required grows exponentially as the number of app
> servers increases linearly.  Yeah, I know, it's ridiculous.

I am not sure I understand this at all, but it sounds like you have created
a workgroup with a hub when what you want is a hub and spoke server
client/system with a switch.  very odd.

> We discussed ripping that design out and basically making a
> centralized cache process, so that each app server only has to talk to
> 1 process (though there might be a backup process or two.)

With a couple of processors and a well written threaded COM server (or maybe
something along the lines of how Medusa is designed to avoid threads) this
seems like a reasonable idea.

<snip>

> > > The only real state I need to persist across connections is the actual
> > > database connection object, since these can be so expensive to obtain
> > > (about 3 or 4 seconds in my tests.)
> >
> > That seems slow, even for win32.  On my win2k server, Python can create
> > literally hundreds of ADO connection objects (to an Access db!) in that
much
> > time.
>
>
> We're talking about ODBC connections to MS Sql Server and/or Oracle
> here.  The slowdowns appear to be in either ODBC itself or the
> Python/ODBC layer (which has given us a number of headaches and
> stability problems in general ...)  We're using the odbc.pyd module
> that
> comes with Python 2.1.1.

I don't know much about ODBC from Python, but ADO can use ODBC, and if you
are on win32 it might not be a bad idea.  From the notes above, it sounds
like the bottleneck could be elsewhere and just happens to be visible while
making the db connections.


> > > The most complicated
> > > objects we will be passing will likely be lists of tuples with varying
> > > simple types inside (ie, database record sets.)
> > >
> > watch out for tuples and COM ... use lists.
>
> That's a little scary.  Any particular reason why?

Search Google for the full answer, but when Python COM servers return tuples
to VB clients, the clients can't understand the data.  Lists, however, come
back as variant arrays. Mark Hammond has posted the reason for this, but I
don't remember it.

-d