From: Hancock, David (DHANCOCK) <DHANCOCK@arinc.com> - 2002-03-03 16:43:33
Tripp: Thanks very much for the tip about locking the connection while in
use. That seems to have cleared up the segmentation faulting. I've got a lot
to learn ...
Now I'm seeing a large percentage of the benchmarker requests returning no
data, and I'm pretty sure that'll be fixed by closing and reopening the
connection in the try/finally block as you suggested.
I appreciate the help.
David Hancock | dhancock@... | 410-266-4384
From: Tripp Lilley [mailto:tlilley@...]
Sent: Saturday, March 02, 2002 3:15 PM
To: Hancock, David (DHANCOCK)
Subject: Re: [Webware-discuss] WebKit seg-faulting when connecting to Oracle
On Sat, 2 Mar 2002, Hancock, David (DHANCOCK) wrote:
> (Apache benchmarker) and have it make a couple thousand requests, with
> 10-40 concurrent. With only a couple concurrent requests, no
> problems. With 10 or more, I get a seg fault pretty quickly.
I have no Oracle experience, but I'm going to go out on a limb and guess
that the driver you're using isn't thread-safe, or isn't being used by the
Python wrappers in a thread-safe manner.
Just off the top of my head, I'd create a per-connection wrapper object that
uses a reentrant lock (see threading.RLock) to lock access to each
(more comments follow code snippet)
> class dhPage(ExamplePage):
> import DCOracle2
> dbconn = DCOracle2.connect('scott/tiger@...')
> def writeBody(self):
> self.write('<h3>select * from emp results</h3>')
> res = dhPage.dbconn.execute('select * from emp')
> list = dhPage.dbconn.fetchall()
Yeah, I'm pretty sure you're running into a thread-safety issue here. I'm
willing to bet that the connection object is barfing all over itself when
you end up with multiple threads running queries and trying to fetch their
Here's a really cheesy rewrite:
import threading.RLock as RLock
def __init__ (self, init):
self._conn = DCOracle2.connect(init)
self._lock = RLock()
def lock (self):
def unlock (self):
def doquery (self, query):
results = 
results = self._conn.fetchall()
## this finally / unlock is very important
## to make sure that other requests don't hang
## if the query or something barfs.
## You might want to harden it a bit more by
## catching the exception and possibly closing /
## reopening the connection.
def __init__ (self):
self._conn = SafeConnection('scott/tiger@...')
def writeBody (self):
res = self._conn.doquery('select * from emp')
# ... etc.
Of course, you don't -have- to break the connection and lock out into a
separate object, but if you -do-, then you'll have an easier time putting
this into a pool later.