On Sun, Sep 17, 2006 at 10:59:48AM -0700, Dean Arnold wrote:
> (I've added dbi-dev as this seems relevant)
>
> Tim Bunce wrote:
> >On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
> >>On Sat, 16 Sep 2006, Dean Arnold wrote:
> >>
> >>>I think your best bet might be to work with the DBD::mysql maintainers
> >>>to implement some driver-specific nonblocking versions of
> >>>execute/prepare (and maybe fetch), as well as support for
> >>>'out of band' cancel.
> >>That's an interesting idea.
> >
> >For any driver that uses a network socket to connect you could close()
> >the socket in the signal handler to (relatively) safely timeout.
> >
> >Should be fairly clean/safe for the db client library state, though
> >unsafe signals means there's still a chance perl's internal state could
> >be corrupted.
> >
> >On the server-side the query may be left running on databases that
> >don't detect disconnects (which I think still includes mysql).
> >
> >A minor problem with this approach is how to determine the socket file
> >descriptor. For drivers that don't/can't make the socket fd available,
> >it requires checking which fd's are open before and after the connect.
> >Kludgy but effective.
>
> Yow...how many client libs surface the socket descriptor ? Not too many
> I'm aware of. And the 'sift and kill' approach of finding fd's is likewise
> an opportunity for disaster, since you don't know how many fd's may have
> been opened in the process of setting up a connection, and some platforms
> don't always update fd status as quickly as one might like (I've been down
> this particular road to hell for similar purposes). And just dumping the
> connection is a pretty severe reaction to something most DBMS's actually
> have i/f's to handle gracefully.
If the driver has an i/f to handle it gracefully then the driver should
provide it. I was just exploring options for drivers stuck with db
interfaces that don't provide a nice way to timeout a session.
> >Would be nice to generalise it. There was talk sometime ago (perhaps on
> >dbi-dev) of extending the DBI api along these lines:
> >
> > $id = $dbh->{SessionId};
> >
> > $dbh->kill_session($id);
> >
> >Would certainly be simple for me to add to the DBI. Then it's just a
> >simple matter of getting the drivers to implement it :)
>
> Er, but how ? Unless/until the DBI is threadsafe, the only way
> for kill_session() to work is by breaking the DBD out of the
> current blocking request. Which I assume is to be accomplished
> by throwing signals around ?
Or using another process as Sam mentioned.
> Keep in mind that the behavior of various DB client libs wrt signals
> on any given platform is certainly not standardized; some blow up, some
> require extra API calls to handle things, others just swallow the signal.
Sure, though I doubt any do that with SIGALRM, and Sys::SigAction
provides a way to regain control. (What it doesn't provide is a way to
get the old (db client lib) signal handler so that your new signal
handler can call it explicitly.)
> Oh, and then there's the little matter of non-POSIX platforms. Trying
> to reliably use Perl + fork + signals + some external library on Win32
> will certainly keep a developer busy for a few days.
> Once an app (or DBD) is down the rabbit hole of a DBMS client library,
> any attempt to standardize such behavior is likely to meet with limited
> success.
All I'm suggesting is one attribute and one method that, I hope, will
address 80% of the need with 20% of the effort. Such is the DBI way.
> Which brings me back to the notion of non-blocking requests. Assuming
> many/most client libs do support an async capability, and a OOB
> cancel, then it should be possible to standardize the behavior
> externally.
Attempting to standardize, let alone implement, non-blocking requests
for the current DBI is a far bigger task than the above.
On the other hand, I'd be *delighted* if you, or anyone else, would like
to champion the work.
Tim.
