Dave Rogers wrote:
> >Is this something that would be appropriate to put in the main code base
> >that would be enabled if Webware was running on Windows and configured for
> >this via the config file?
>
> Yes, I know I might be using ADO to access an SQL Server database from Webware soon.
I'll attach my modified version of ThreadedAppServer.py -- use at your own risk...
If you're using ADO and/or ODBC for database access, you can configure the ODBC data source for connection pooling. This speeds things up significantly. The catch is that you have to keep at least one connection to a data
source open at all times; then, all connections to that data source are pooled automatically. One way to do this is to store an open connection to each data source in the application object. Right now, I'm using a mixin
class for database access that I mix into my classes derived from Page:
##############################
from win32com.client import Dispatch
# This class can be mixed into a Page-derived class to give it
# the ability to talk to the MyConnection database using ADO
# connection pooling.
class DatabaseMixin:
def connection(self, connection_string='MyConnection'):
#### Do I need to use thread locking here?
# See if the application is storing a permanent connection with the given
# connection string
try:
appconnections = self.application().connections
except AttributeError:
appconnections = self.application().connections = {}
# Store a permanently open connection to the database if one isn't already
# stored there
if not appconnections.has_key(connection_string):
conn = Dispatch('ADODB.Connection')
conn.Open(connection_string)
appconnections[connection_string] = conn
# Now open up a connection to the database and return it. This
# connection will come out of the ADO connection pool due to
# the magic of ADO connection pooling. Basically, as long
# as your application has at least one open connection to a
# given data source at one time, ADO will pool the connections
# to that source.
conn = Dispatch('ADODB.Connection')
conn.Open(connection_string)
return conn
def recordset(self, Source, ActiveConnection=None, CursorType=-1, LockType=-1, Options=-1):
rs = Dispatch('ADODB.Recordset')
if not ActiveConnection:
ActiveConnection = self.connection()
rs.Open(Source, ActiveConnection, CursorType, LockType, Options)
return rs
####################################
Then I can have code like this in my Page classes:
def writeBody(self):
rs = self.recordset('SELECT Name FROM Table ORDER BY Name')
self.writeln('<table>')
while not rs.EOF:
name = rs.Fields('Name').Value
self.writeln('<tr><td>%s</td></tr>' % name)
rs.MoveNext()
self.writeln('</table>')
This would be nicer with more Python wrappers around the ADO stuff to make accessing fields and looping cleaner. Someone posted a message to comp.lang.python about a wrapper they had written to make ADO access look like
standard Python DBI, but I haven't looked at it yet.
You can use the Performance Monitor to see how many connections there are to your SQL Server database to verify that connection pooling is working.
> I'd actually like portability from Windows to Linux preserving database access. Any ideas how that can be done? I've never done ODBC from Linux but I do know that there is a unixODBC program out there that faciliates it.
mxODBC is probably the way to go for portability. http://starship.python.net/crew/lemburg/mxODBC.html
I've never used it though.
--
- Geoff Talvola
Parlance Corporation
gtalvola@...
|