Not sure why yet, but for some reason I now have to do start/end
transaction around around my sql calls (postgres). Otherwise I will
get a error "another command is already in progress" after the first
connection, which I wasn't getting before. After doing this all is
working good (both with and without APR_HAS_THREADS set in mod_dbd.c).
While trying to debug this I found my original thought:
I think it might have to do with allocating a dbd from the connection
pool when it needs to be from the server pool for persist connections.
non-persist connection can use the connection pool.
was wrong as because it does the right thing inside of ap_dbd_open, but
I do have a question about code in ap_dbd_open. If the connection is
not persist, should it use the passed in pool (the connection pool,
request pool for acquire functions or temp pool if called directly)
instead of the server pool? Currently every thing with the DB handle
will be closed correctly, but I think it will leak sizeof(ap_dbd_t) for
each call of ap_dbd_open because that memory is cleaned up from the
server pool (instead of connect, request or temp pool).
Brian
On Oct 1, 2005, at 4:33 AM, Nick Kew wrote:
On Saturday 01 October 2005 01:26, Brian J. France wrote:
Thanks for the work!
I am having problems with it on the second connection, first
connection
works with multiple calls to ap_dbd_cacquire.
I think it might have to do with allocating a dbd from the connection
pool when it needs to be from the server pool for persist connections.
non-persist connection can use the connection pool.
I don't have time to dig into right now, but will try this weekend.
Thanks for the feedback. Are you running the patch against current SVN
(i.e. after the fixes we made yesterday), or something older?
