On Nov 3, 4:29 pm, rehs...@googlemail.com (Jens Rehsack) wrote:
> 2010/11/3 Martin J. Evans <martin.ev...@easysoft.com>:
>
> > 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?
