On Mon, Jul 05, 2004 at 10:37:01PM +0100, John Escott wrote:
> OK, Tim's prompting (off list) has spurred me into action. I'm posting
> back to the list, just in case anyone else is interested.
Thanks John.
> There's some good news and some bad news
>
> First the good news: setting mode to "threads" in the config file and
> restarting dbiproxy certainly allows multiple connections. I wrote a
> small test script [1 -- below] which did a cycle of deletes, inserts,
> updates and selects and ran it from several hosts concurrently and it
> seemed to work ok (at least for several hundred iterations).
> My setup is clients running on Linux, dbiproxy on Win2000 using ODBC to
> Centura SQLBase. [NB, I have ActiveState 5.8.3 build 809, which comes with
> Storable 2.09, which does not have the fix for threads -- that came in
> with 2.10]
>
> Now for the bad:
> 1. If the client dies (I killed it) or fails to disconnect, the thread in
> dbiproxy stays alive (I guess) and keeps its dbi handle, sometimes after
> reporting the error:
> <date/time> err, 3, Child died: Error while reading socket: Bad
> file descriptor at C:/Perl/site/lib/RPC/PlServer/Comm.pm line 110.
> Other times, dbiproxy gives no error message.
> If the handle has any locks, they're not released. I tried changing
> connect to connect_cached in the client, but it made no difference. I had
> to kill dbiproxy to release the database connections.
> I guess this problem is something to do with (a) RPC::Pl* or (b)
> Net::Daemon or (c) the threads in my perl. I've no experience of the
> forking method of multiple connections, so I can't speculate on (a) or
> (b). In case it's (c), I've included a perl -V at [4] below.
It's probably simple to fix. Might just need an overridden Close() method
in DBI::ProxyServer. Anyone interested in debugging? (I can't at the moment.)
> If the client disconnects cleanly, the database connection gets released.
>
> 2. [Concerning DBI::Proxy, rather than dbiproxy] My first test was just a
> quick one with AutoCommit = 1, but even so, the DB occasionally detected
> deadlock (it uses page-level locks for updates). When I tried using
> proper transactions with begin_work and commit, DBD::Proxy doesn't seem to
> allow you to start a new transaction after committing a previous one: the
> sequence
> $dbh->commit;
> $dbh->begin_work;
> produces the error
> DBD::Proxy::db begin_work failed: Already in a transaction at
> <line no of the begin_work>.
> If I reset AutoCommit between the 2 ($dbh->{AutoCommit} = 1), then the
> error goes away. [3] below has a DBI_Trace=2 of what went on.
Um, probably related to how client and proxy server keep in AutoCommit
state in sync. I presume the same thing happens when not in multi-threaded
mode. I'll happily guide anyone interested towards fixing this.
Otherwise it'll get queued for now.
> So, it looks encouraging on the Storable front, but there seems to be
> another problem elsewhere.
Thanks John.
Tim.
