Re: $SIG{INT} tampering during DBI->connect on Oracle

On Nov 3, 4:29 pm, [email protected] (Jens Rehsack) wrote:
> 2010/11/3 Martin J. Evans <[email protected]>:
>
> > Is it really worth changing DBD::Oracle for what effectively is a one liner?
>
> No, because it's not safe for each Oracle configuration. It must keep up to the
> developer to figure out when it's safe.
>
> > Perhaps some better documentation on connect would suffice once we get to the bottom of Brian's observation.
>
> Yes :)
>

Additional documentation would be helpful but it does not solve the
problem when the user is using a high-level tool such as DBIx::Class
or even Apache::DBI (e.g. Apache::DBI->connect_on_init($data_source,
$username, $auth, \%attr)) that manages the connection for the user.
With these types of tools, it is often difficult to have code executed
in the appropriate scope.  For instance, with DBIx::Class:

  {
    local $SIG{INT};
    MyDB::Schema->connect($dbi_dsn, $user, $pass, \%dbi_params); #
this does not do a DBI->connect
  }

  # later on...
  $schema->resultset('Artist')->search(...); # this does the connect

I don't know if it's realistic to expect every tool that builds on top
of DBI to provide a way for the user to inject this localizing
functionality at the appropriate point.  As a compromise solution,
perhaps an additional DBI attribute could be added that would allow
the user to either specifically localize the INT signal or more
flexibly, specify a set of signals that need to be localized.
Something like this:

  DBI->connect($dbi_dsn, $user, $pass, { ora_loc_sigs => ['INT'] });

I've created another gist here https://gist.github.com/660058#file_strace_of_interrupted_process.txt
that shows some Perl code and a relevant part of that processes strace
output.  Is there any further information that I can provide that
would be helpful to diagnose what is actually triggering this behavior
for me?