Re: Announcement/Request for Comments: DBIx::Call
On Thu, 25 Nov 2004 16:23:05 +0900, Thilo Planz wrote: Hi THilo After some discussion with the Perl monks, I decided that DBIx::Call would be a good name for putting the module on CPAN. The ::Call part is terribly vague. Couldn't you add something meaningful tio it? -- Cheers Ron Savage, [EMAIL PROTECTED] on 25/11/2004 http://savage.net.au/index.html
Re: Zombie handles when trapped by a signal
On Wed, Nov 24, 2004 at 04:52:08PM -0800, Henri Asseily wrote:
I have slammed into a wall in my quest for reliable failover and high
availability in DBI. I don't know if this discussion should be in
dbi-users or dbi-dev, but here goes:
It's a user problem, albeit an advanced one, so dbi-users is best.
High availability necessitates a good timeout handling system. If
execution of an sql statement or stored procedure takes too long, one
should have the opportunity to kill it and fail over to a less
overloaded server.
One problem is in the timeout handling in Perl (and Unix in general).
The standard $SIG{ALRM} technique utterly fails when trying to trap
$sth-execute(), and never gets triggered.
That problem has now been resolved thanks to Lincoln Baxter's excellent
Sys::SigAction module (at least for Unix machines) which utilizes all
the techniques (POSIX sigaction, SIGALRM...) to ensure proper signal
handling.
But there's another more subtle problem that I only today finally
managed to get to the bottom of:
Assuming you use Sys::SigAction and you properly trap the execute()
call, you get nailed by DBI's aggressive sanity checking.
You're jumping to conclusions. The aggressive sanity checking is
helping you here.
Suppose you have code like the following (copied from my upcoming
DBIx::HA 0.9x module):
eval {
my $h = set_sig_handler(
'ALRM',
sub { $timeout = 1; die 'TIMEOUT'; },
{ mask=['ALRM'],
safe=1 }
);
alarm(10);
$res = $sth-SUPER::execute;
alarm(0);
};
alarm(0);
If the alarm is triggered, then your statement handle ($sth) gets
automatically corrupted with no way to get rid of it. This in turn will
continuously add active kids to your database handle and corrupt everything.
http://search.cpan.org/~timb/DBI/DBI.pm#Signal_Handling_and_Canceling_Operations
explains that non-deferred signal handling is fundamentally unsafe
and that the handles in use at the time the signal is handled may
not be safe to use afterwards.
These are not limitations of the DBI. They are fundamental to signal
handling in any language.
Below is the result of triggering the above alarm:
null:(in cleanup) dbih_setup_fbav: invalid number of fields:
-1, NUM_OF_FIELDS attribute probably not set right at
dbih_setup_fbav is called only when you bind columns or fetch a row.
You shouldn't be doing either of those if the execute() failed.
Using trace() should help track down what's happening.
null: DBI handle 0xabf1038 cleared whilst still active at ...
I'd guess that the driver is marking the handle Active before
it waits for results from the database. (Or perhaps the execute
is a re-execute() of an already Active handle.) Need a trace().
null: DBI handle 0xabf1038 has uncleared implementors data at ...
Looks like a bug in DBD::Sybase. When syb_st_destroy is called during
global destruction it does nothing. It should *at least* call
DBIc_IMPSET_off(imp_sth); That tells the DBI that the driver has
properly cleaned up, then the DBI won't complain about it.
The statement handle was created but was never populated with the
execution results, so it's in a weird half-alive state.
For example, the DBIc_NUM_FIELDS is -1, which makes dbih_setup_fbav()
croak. Similarly, DBIc_ACTIVE is still true.
The fact that dbih_setup_fbav is called seems most likely to be a
bug in your code. The fact that Active is set seems most likely to
be a bug in DBD::Sybase.
What's the best strategy to deal with these zombies?
Fix the bugs :)
Even when you've done that there's still a remaining issue: handles
in use at the time the signal is handled may not be safe to use
afterwards.
That's actually not worded strongly enough. If the signal fired
while using a statement handle then the corresponding database
handle may not be safe to use. (Not because of any problem in
the DBI that I'm aware of, but because the database client code
and/or driver may have been left in a corrupted state.)
For reliability you'll need to destroy the database handle and
reconnect.
Tim.
Re: Zombie handles when trapped by a signal
On Nov 24, 2004, at 10:14 PM, Lincoln A. Baxter wrote:
Hi Henri,
I have some questions/avenues for you to pursue:
1) What happens when you change safe=1 to safe=0 in this code?
You end up getting the same as the standard $SIG{ALRM} behavior, i.e.
the alarm never triggers.
2) What happens if you close the entire dbh at this point (reopen it
later)? -- its a thought?
I don't know, but I certainly do not want that (which is why I didn't
try it). The concept is to do the execute with a timeout. If the
timeout triggers, retry a select 1. If that fails, then we assume the
db is dead and switch to another one. If it succeeds, then either the
statement is wrong or the database is overloaded, and I still have to
determine the correct course of action. But switching to another
database server automatically is not correct.
3) Which DBD(s) have you tested this with? If more than one, does the
problem occur with all DBD's you have tried? (Which ones have you
tried?) I would want to know if this is DBD behavior or DBI code that
is freaking out or getting corrupted by the signal. We could be
dealing
with stacked Signal handlers. Check the source of the DBD you are
using
for the use of signal() or sigaction().
I've been using DBD::Sybase exclusively at this point, with ASE and
Sybase IQ.
4) Have you considered looking at the output with DBI_TRACE=n Where n
is
greater than 0 -- you can turn trace on just before the statement with
Yep that's my next step to do. That will help me determine what to
patch in DBI.
5) If you are running on linux, can you do this with strace, and show
us
the output? If on Sun... same question but use truss. (Don't recall
know what does the equiv on AIX or HPUX).
Will do as well.
On Wed, 2004-11-24 at 16:52 -0800, Henri Asseily wrote:
I have slammed into a wall in my quest for reliable failover and high
availability in DBI. I don't know if this discussion should be in
dbi-users or dbi-dev, but here goes:
High availability necessitates a good timeout handling system. If
execution of an sql statement or stored procedure takes too long, one
should have the opportunity to kill it and fail over to a less
overloaded server.
One problem is in the timeout handling in Perl (and Unix in general).
The standard $SIG{ALRM} technique utterly fails when trying to trap
$sth-execute(), and never gets triggered.
That problem has now been resolved thanks to Lincoln Baxter's
excellent
Sys::SigAction module (at least for Unix machines) which utilizes all
the techniques (POSIX sigaction, SIGALRM...) to ensure proper signal
handling.
But there's another more subtle problem that I only today finally
managed to get to the bottom of:
Assuming you use Sys::SigAction and you properly trap the execute()
call, you get nailed by DBI's aggressive sanity checking.
Suppose you have code like the following (copied from my upcoming
DBIx::HA 0.9x module):
eval {
my $h = set_sig_handler(
'ALRM',
sub { $timeout = 1; die 'TIMEOUT'; },
{ mask=['ALRM'],
safe=1 }
);
alarm(10);
$res = $sth-SUPER::execute;
alarm(0);
};
alarm(0);
If the alarm is triggered, then your statement handle ($sth) gets
automatically corrupted with no way to get rid of it. This in turn
will
continuously add active kids to your database handle and corrupt
everything.
Below is the result of triggering the above alarm:
null:(in cleanup) dbih_setup_fbav: invalid number of fields:
-1, NUM_OF_FIELDS attribute probably not set right at
null: DBI handle 0xabf1038 cleared whilst still active at ...
null: DBI handle 0xabf1038 has uncleared implementors data at ...
dbih_clearcom (sth 0xabf1038, com 0xaeb79b8, imp
DBD::Sybase::st):
FLAGS 0x180057: COMSET IMPSET Active Warn ChopBlanks PrintWarn
PARENT DBIx::HA::db=HASH(0xa21e008)
KIDS 0 (0 Active)
IMP_DATA undef
LongReadLen 32768
NUM_OF_FIELDS -1
NUM_OF_PARAMS 0
The statement handle was created but was never populated with the
execution results, so it's in a weird half-alive state.
For example, the DBIc_NUM_FIELDS is -1, which makes dbih_setup_fbav()
croak. Similarly, DBIc_ACTIVE is still true.
Should there be an additional field for a handle that tells us if it's
not in a fully active state, and if so then we have carte blanche to
wipe it?
What's the best strategy to deal with these zombies?
I can provide a patch when I dig deeper.
H
--
Re: RE: prepared statement: automatically removed trailing spaces
OK, I found it in the docs- but to tell the truth, I wouldn't understand it without my knowledge now. It REALLY should be stated clearly, that the default CHANGES THE PARAMETERS - btw, I still don't understand why. I think this is really an important issue, that parameters are AUTOMATICALLY changed, and that should be stated as clearly as possible. There should be a warning in DBI too, because that's the first place to look for most people. Frank -Original Message- From: Michael A Chase tech [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 3:07 AM To: Steinhauer, Frank (CAM) Cc: '[EMAIL PROTECTED]' Subject: Re: prepared statement: automatically removed trailing spaces On 11/24/2004 04:55 AM, Steinhauer, Frank (CAM) said: ... What actually happens is that the default binding for DBD::Oracle is SQL_VARCHAR. When Oracle OCI sees that type, it automatically strips trailing spaces leaving '' if that's all there was. Then '' is interpreted as a NULL by Oracle. Binding as SQL_CHAR prevents the space stripping. ... See http://groups.google.com/groups?hl=enlr=threadm=E3A8A8F741B2D611ACA800508B 6F33D4381467%40chitmd03.nt.il.nbgfn.comrnum=2prev=/groups%3Fq%3Dbind_param %2Bspace%26hl%3Den%26lr%3D%26selm%3DE3A8A8F741B2D611ACA800508B6F33D4381467%2 540chitmd03.nt.il.nbgfn.com%26rnum%3D2 Why there is no hint about something important like that in the documentation of DBI and DBD-Oracle? I think that's a really important issue!!! It's been a basic problem with Oracle since forever that it treats '' as NULL. The automatic removal of trailing spaces is mentioned in `perldoc DBD::Oracle` or http://search.cpan.org/dist/DBD-Oracle/Oracle.pm. Search for ora_ph_type. = ora_ph_type The default placeholder data type for the database session. The TYPE or ora_type attributes to bind_param in DBI and bind_param_inout in DBI override the data type for individual placeholders. The most frequent reason for using this attribute is to permit trailing spaces in values passed by placeholders. = -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Cthulhu in 2004. Don't settle for the lesser evil.
Re: Zombie handles when trapped by a signal
That *might* be a problem with DBD::Sybase and/or with the way Sybase
client libs use signals.
As Lincoln suggested, a couple of traces might be useful.
I'm running under mod_perl, DBI 1.45 and DBD::Sybase 1.04. I'm
attaching a number of traces.
The first listing below is what happens under $sth-trace(15) when
there is no timeout and all goes well:
DBIx::HA::st=HASH(0x832d4c0) trace level set to 0x0/15 (DBI @
0x0/0) in DBI 1.45-nothread (pid 20783)
- execute for DBD::Sybase::st
(DBIx::HA::st=HASH(0xad19a14)~0x832d4c0)
syb_alloc_cmd() - CS_COMMAND 80af758 for CS_CONNECTION 8f4f2e0
syb_st_execute() - ct_command() OK
syb_st_execute() - ct_send() OK
st_next_result() - ct_results(4043) == 1
ct_res_info() returns 1 columns
ct_describe(0): type = 8, maxlen = 4
describe() - col 0, type 8, realtype 8
describe() retcode = 1
st_next_result() - lasterr = 0, lastsev = 0
- execute= -1
---
Then the DESTROY of that statement handle happens properly:
- DESTROY for DBD::Sybase::st (DBIx::HA::st=HASH(0x832d4c0)~INNER)
syb_st_finish() - flushing
dbih_setup_fbav for 1 fields = 0xad2279c
syb_st_fetch() - 0/4/8
st_next_result() - ct_results(4047) == 1
st_next_result() - ct_results(4046) == 1
ct_results(4046) final retcode = -205
st_next_result() - lasterr = 0, lastsev = 0
syb_st_fetch() - st_next_results() == 4046
syb_st_fetch() - resetting ACTIVE, moreResults, dyn_execed
syb_st_finish() - resetting ACTIVE, moreResults, dyn_execed
syb_st_destroy: called on ae1e200...
syb_st_destroy(): freeing imp_sth-statement
ct_cmd_drop() - CS_COMMAND 80af758
syb_st_destroy(): cmd dropped: 1
- DESTROY= undef
---
Now below is what happens when a timeout is caught and the execution is
stopped by the signal:
DBIx::HA::st=HASH(0x832d4c0) trace level set to 0x0/15 (DBI @
0x0/0) in DBI 1.45-nothread (pid 20784)
- execute for DBD::Sybase::st
(DBIx::HA::st=HASH(0xad1a364)~0x832d4c0)
syb_alloc_cmd() - CS_COMMAND 80af758 for CS_CONNECTION 8f4f2e0
syb_st_execute() - ct_command() OK
syb_st_execute() - ct_send() OK
HERE THE EXECUTION TIMES OUT AND IS STOPPED BY THE SIGNAL
- finish for DBD::Sybase::st
(DBIx::HA::st=HASH(0xad1a364)~0x832d4c0)
syb_st_finish() - flushing
(in cleanup) dbih_setup_fbav: invalid number of fields: -1,
NUM_OF_FIELDS attribute probably not set right at /xxx/xxx/xxx.pm line
207.
DBI handle 0xad1a364 cleared whilst still active at /xxx/xxx/xxx.pm
line 207.
DBI handle 0xad1a364 has uncleared implementors data at /xxx/xxx/xxx.pm
line 207
dbih_clearcom (sth 0xad1a364, com 0xad26198, imp DBD::Sybase::st):
FLAGS 0x180057: COMSET IMPSET Active Warn ChopBlanks PrintWarn
PARENT DBIx::HA::db=HASH(0x919e514)
KIDS 0 (0 Active)
IMP_DATA undef
LongReadLen 32768
NUM_OF_FIELDS -1
NUM_OF_PARAMS 0
---
Here's a verbose strace of the call that times out and zombifies the
statement handle:
select(32, [31], [], [31], {0, 0}) = 0 (Timeout)
fcntl64(5, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
fcntl64(5, F_SETFL, O_RDWR) = 0
send(5, \17\1\0\31\0\0\0\0!\f\0\0\0\0use logging, 25, 0) = 25
recv(5, \4\1\0l\0\0\0\0\343\21\0\1\7logging\7logging\345D\0E...,
3072, 0) = 108
send(5, \17\1\0\17\0\0\0\0\246\4\0\1\31\1\0, 15, 0) = 15
recv(5, \4\1\0\21\0\0\0\0\375\0\0\2\0\0\0\0\0, 3072, 0) = 17
time([1101370634]) = 1101370634
write(2, [Thu Nov 25 00:17:14 2004] null:..., 189) = 189
rt_sigprocmask(SIG_BLOCK, ~[], [RTMIN], 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], ~[KILL STOP], 8) = 0
rt_sigaction(SIGALRM, {0x406c4c70, [], SA_RESTORER, 0x4009d4f8},
{SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x406c4c70, [ALRM], SA_RESTORER, 0x4009d4f8},
NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
alarm(8)= 0
send(5, \17\1\0\26\0\0\0\0!\t\0\0\0\0select 1, 22, 0) = 22
recv(5, \4\1\\0\0\0\0a\21\0\0\0\1\0\0\0\0\0\0\20\0\0\0\7\0...,
3072, 0) = 48
alarm(0)= 8
rt_sigprocmask(SIG_BLOCK, ~[], [RTMIN], 8) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], ~[KILL STOP], 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x406c4c70, [ALRM], SA_RESTORER,
0x4009d4f8}, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP], NULL, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
alarm(0)= 0
time([1101370634]) = 1101370634
write(2, [Thu Nov 25 00:17:14 2004] null:..., 69) = 69
time([1101370634]) = 1101370634
write(2, [Thu Nov 25 00:17:14 2004] null:..., 77) = 77
time([1101370634]) = 1101370634
write(2, [Thu Nov 25 00:17:14 2004] null:..., 302) = 302
snip Carp stuff
open(/usr/lib/perl5/5.8.4/Carp/Heavy.pm, O_RDONLY|O_LARGEFILE) = 6
ioctl(6,
Re: Announcement/Request for Comments: DBIx::Call
On Thu, Nov 25, 2004 at 04:23:05PM +0900, Thilo Planz wrote: Hi all, I have been using Oracle PL/SQL fairly extensively these days, and came up with a module that creates Perl wrappers for PL/SQL procedures, so that I can call them just like Perl functions (without the need to write SQL statements or to manually bind parameters). After some discussion with the Perl monks, I decided that DBIx::Call would be a good name for putting the module on CPAN. (Although only Oracle is implemented now, it could be made to work with other databases). Any objections to what it does, how it does it, or the name? DBIx::Call is a little too short. DBIx::ProcedureCall may be a mouthful and doesn't mention functions, but it is very clear, and better for it. Do you think it is at all useful? Sure. I've wanted to add something along these lines to the DBI. But I've not had time to compare the various modules and try to distill the best of each. This is a useful addition to the mix. I'd be interested to know what users of other databases think of the API. Specifically if the API would be too limited for their database. One quick suggestion... currently the performance is limited by using prepare(). You could allow the importer to specify if they'd like to use prepare_cached for extra speed: use DBIx::ProcedureCall qw(sysdate:cached dbms_random.initialize); so sysdate($dbh) then uses prepare_cached(). Tim. Module: http://perl-pad.sourceforge.net/dbi/DBIx-Call-0.02.tar.gz Perldoc : http://perl-pad.sourceforge.net/dbi/Call.html Thread on Perlmonks: http://perlmonks.org/index.pl?node_id=410058 Cheers, Thilo
Re: Zombie handles when trapped by a signal
On Thu, 2004-11-25 at 07:36, Henri Asseily wrote: On Nov 24, 2004, at 10:14 PM, Lincoln A. Baxter wrote: 3) Which DBD(s) have you tested this with? If more than one, does the problem occur with all DBD's you have tried? (Which ones have you tried?) I would want to know if this is DBD behavior or DBI code that is freaking out or getting corrupted by the signal. We could be dealing with stacked Signal handlers. Check the source of the DBD you are using for the use of signal() or sigaction(). I've been using DBD::Sybase exclusively at this point, with ASE and Sybase IQ. Have you considered letting Sybase OpenClient's timeout functionality handle this instead of using signals? I realize that it's not portable, but it might be better behaved. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
Re: Zombie handles when trapped by a signal
On Thu, 2004-11-25 at 09:39, Henri Asseily wrote: That *might* be a problem with DBD::Sybase and/or with the way Sybase client libs use signals. As Lincoln suggested, a couple of traces might be useful. I'm running under mod_perl, DBI 1.45 and DBD::Sybase 1.04. I'm attaching a number of traces. Now below is what happens when a timeout is caught and the execution is stopped by the signal: DBIx::HA::st=HASH(0x832d4c0) trace level set to 0x0/15 (DBI @ 0x0/0) in DBI 1.45-nothread (pid 20784) - execute for DBD::Sybase::st (DBIx::HA::st=HASH(0xad1a364)~0x832d4c0) syb_alloc_cmd() - CS_COMMAND 80af758 for CS_CONNECTION 8f4f2e0 syb_st_execute() - ct_command() OK syb_st_execute() - ct_send() OK HERE THE EXECUTION TIMES OUT AND IS STOPPED BY THE SIGNAL - finish for DBD::Sybase::st (DBIx::HA::st=HASH(0xad1a364)~0x832d4c0) syb_st_finish() - flushing (in cleanup) dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS attribute probably not set right at /xxx/xxx/xxx.pm line 207. OK - that one's pretty obviously a bug - where the destroy tries to flush (fetch) all the results, but the result structure hasn't been set up. Tim may be correct that the active flag is being set too early on the handle - I'll take a look at the sequence again. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
Re: Announcement/Request for Comments: DBIx::Call
On Thu, 2004-11-25 at 12:37, Tim Bunce wrote: On Thu, Nov 25, 2004 at 04:23:05PM +0900, Thilo Planz wrote: After some discussion with the Perl monks, I decided that DBIx::Call would be a good name for putting the module on CPAN. (Although only Oracle is implemented now, it could be made to work with other databases). I'd be interested to know what users of other databases think of the API. Specifically if the API would be too limited for their database. The API might work for Sybase, though I haven't really looked at it that closely. The main issue is of course that Sybase treats a stored procedure call (or RPC) exactly as any other database query and returns one or more result sets, so you'd have to fiddle around with the output to get at the data you want. Note that DBD::Sybase already allows direct RPCs to stored procedures via a normal prepare() call. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
DBD::Sybase under Cygwin
Here's a little how-to to build DBD::Sybase in the Cygwin (http://www.cygwin.com) environment under Windows. First - you need to have Sybase OpenClient installed. This is pretty easy to get from http://www.sybase.com/ase_1252devel/. Second, you need to map the entry points to the Sybase DLLs to something that gcc can use. I've built a set of .a files (libcs.a, libct.a and libblk.a) that provide these entry points - you can get them from http://www.peppler.org/downloads/cygwin.tar.gz. Install the .a files in /usr/local/lib so that the build will find them easily. Third, grab the most recent dev release of DBD::Sybase 1.04_14 or later, available from http://www.peppler.org/downloads/). Now build this as usual (perl Makefile.PL, etc) making sure that the SYBASE and SYBASE_OCS environment variables are set correctly. Et voilà! If you don't want to download/use the dev release, you can achieve the same result like this: After installing the cygwin libct/cs/blk.a files, run perl Makefile.PL in the DBD::Sybase source directory. Now edit the generated Makefile, and add -D_MSC_VER=800 to the CCFLAGS macro, and change the EXTRALIBS and LDLOADLIBS macros to EXTRALIBS= -lcs -lct -lblk LDLOADLIBS= -lcs -lct -lblk and now run make. For those of us who prefer a Unix-like feel this gives a nice alternative to the ActiveState version of perl. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
DBI use failure with DBI/DBD::Oracle on AIX 5.2
After being prepped by experiences of others in the README.aix file. I beleive
(see below), I have a good installation. But on running my fist test prog I
appear to have a permissions problem. This litlle ditty does not fail when run
as root, but anyone else and it aborts on the 'use DBI;'.
$ cat ora.pl
#!/bin/perl -w
use DBI;
use strict;
my ($dbname, $user, $passwd) = ('exua', 'remote', 'remote');
#$dbh = DBI-connect(dbi:Oracle:$dbname, $user, $passwd);
#$dbh-do(SELECT * FROM DUAL);
$
$ ./ora.pl
Can't locate loadable object for module DBI in @INC (@INC contains:
/usr/opt/perl5/lib/5.8.0/aix-thread-multi /usr/opt/perl5/lib/5.8.0
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi
/usr/opt/perl5/lib/site_perl/5.8.0 /usr/opt/perl5/lib/site_perl .) at
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 254
BEGIN failed--compilation aborted at
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 254.
Compilation failed in require at ./ora.pl line 3.
BEGIN failed--compilation aborted at ./ora.pl line 3.
$
permissions on the directories and files under /usr/opt/perl5 appear to be OK,
at least world readable. Any ideas?
Perl info
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=aix, osvers=5.2.0.0, archname=aix-thread-multi
uname='aix rocky 2 5 000ad7df4c00 '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
-qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32
-D_LARGE_FILES -qlonglong',
optimize='-O',
cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384
-qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld', ldflags =' -brtl -b32'
libpth=/lib /usr/lib /usr/ccs/lib
libs=-lbind -lnsl -ldbm -ldl -lld -lm -lpthreads -lc_r -lcrypt -lbsd -lPW
perllibs=-lbind -lnsl -ldl -lld -lm -lpthreads -lc_r -lcrypt -lbsd -lPW
libc=/lib/libc.a, so=a, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-bE:/usr/opt/perl5/lib/5.8.0/aix-thread-multi/CORE/perl.exp'
cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp
-bE:$(BASEEXT).exp -bnoentry -lpthreads -lc_r'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under aix
Compiled at Jul 26 2002 13:48:15
@INC:
/usr/opt/perl5/lib/5.8.0/aix-thread-multi
/usr/opt/perl5/lib/5.8.0
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi
/usr/opt/perl5/lib/site_perl/5.8.0
/usr/opt/perl5/lib/site_perl
.
***
The BUILD
using
ORACENV=xlc_r
ORACLE_APPS=/data/exua/usr
ORACLE_HOME=/applications/ora92/app/oracle/product/9.2.0
ORACLE_PATH=/data/exua/usr/oraexe:/applications/mgua/release/bin:/applications/ora92/app/oracle/product/9.2.0/bin
ORACLE_SID=exua
ORACLE_USERID=remote/remote
lonamappu1 (root) /applications/home/holtcc/ext/perlmod/DBI-1.46: perl
Makefile.PL
*** You are using a perl configured with threading enabled.
*** You should be aware that using multiple threads is
*** not recommended for production environments.
Creating DBI::PurePerltest variant: t/zvpp_01basics.t
Creating DBI::PurePerltest variant: t/zvpp_02dbidrv.t
Creating DBI::PurePerltest variant: t/zvpp_03handle.t
Creating DBI::PurePerltest variant: t/zvpp_04mods.t
Creating DBI::PurePerltest variant: t/zvpp_05thrclone.t (use threads)
Creating DBI::PurePerltest variant: t/zvpp_06attrs.t
Creating DBI::PurePerltest variant: t/zvpp_07kids.t
Creating DBI::PurePerltest variant: t/zvpp_08keeperr.t
Creating DBI::PurePerltest variant: t/zvpp_09trace.t
Creating DBI::PurePerltest variant: t/zvpp_10examp.t
Creating DBI::PurePerltest variant: t/zvpp_14utf8.t
Creating DBI::PurePerltest variant: t/zvpp_15array.t
Creating DBI::PurePerltest variant: t/zvpp_20meta.t
Creating DBI::PurePerltest variant: t/zvpp_30subclass.t
Creating DBI::PurePerltest variant: t/zvpp_40profile.t
Creating DBI::PurePerltest variant: t/zvpp_41prof_dump.t
Creating DBI::PurePerltest variant:
Re: Announcement/Request for Comments: DBIx::Call
Tim Bunce wrote: On Thu, Nov 25, 2004 at 04:23:05PM +0900, Thilo Planz wrote: Hi all, I have been using Oracle PL/SQL fairly extensively these days, and came up with a module that creates Perl wrappers for PL/SQL procedures, so that I can call them just like Perl functions (without the need to write SQL statements or to manually bind parameters). After some discussion with the Perl monks, I decided that DBIx::Call would be a good name for putting the module on CPAN. (Although only Oracle is implemented now, it could be made to work with other databases). Any objections to what it does, how it does it, or the name? DBIx::Call is a little too short. DBIx::ProcedureCall may be a mouthful and doesn't mention functions, but it is very clear, and better for it. Also, unless it can be adapted/generalized for most/all DBI drivers that support SPs, it should probably have some sort if Oracleness to it, e.g., DBIx::OraCall. Do you think it is at all useful? Sure. I've wanted to add something along these lines to the DBI. But I've not had time to compare the various modules and try to distill the best of each. This is a useful addition to the mix. I'd be interested to know what users of other databases think of the API. Specifically if the API would be too limited for their database. Pretty nifty, but support for OUT/INOUT params returned as resultset(s) is needed (I see OUTs in the TODO, I assume that covers INOUTs ?). I've actually been hacking something akin to this for SQL::Preproc, and SP CALL support has been a PITA. Also, is there any support for using e.g., - SQL qualifiers on parameters, - SQL literals, - native SQL functions, - etc. in the param list ? Regards, Dean Arnold Presicient Corp.
Re: Zombie handles when trapped by a signal
Hi Henri,
I have read the other posts to this thread, and it does sound like (at
least) a bug in the Sybase driver. Now that I know that the Sybase
client has an internal timeout feature, I am more suspicious the we are
running into multiple handlers on the SIGALRM. (one in sybase code).
Although, quickly scanning the strace output, the could have implemented
that with select(). (now... I cann't remember if select itself uses
alarms... though I did not think it did).
On Wed, 2004-11-24 at 22:36 -0800, Henri Asseily wrote:
On Nov 24, 2004, at 10:14 PM, Lincoln A. Baxter wrote:
Hi Henri,
I have some questions/avenues for you to pursue:
1) What happens when you change safe=1 to safe=0 in this code?
You end up getting the same as the standard $SIG{ALRM} behavior, i.e.
the alarm never triggers.
Hmmm, I think I want to take a closer look at that... I do suspect the
we are running into an issue with Sybase signal handling in addition to
other things. But, I want to do a little testing of Sys::SigAction's
safe flag in this case. Can you construct a script the does this that I
might be able to try against or DBD-Oracle? (and send me your latest HA
module .. if it is needed and it not on CPAN).
2) What happens if you close the entire dbh at this point (reopen it
later)? -- its a thought?
I don't know, but I certainly do not want that (which is why I didn't
try it). The concept is to do the execute with a timeout. If the
timeout triggers, retry a select 1. If that fails, then we assume the
db is dead and switch to another one. If it succeeds, then either the
statement is wrong or the database is overloaded, and I still have to
determine the correct course of action. But switching to another
database server automatically is not correct.
Tim recommended cleaning up the entire dbh in another message, and I
would too, even after the DBD-Sybase bug is fixed. Even with the safe
flag we have to assume that signals are inherently unsafe. That is how
we handle all DB timeouts on a Database in code we have written.
I think that doing a select 1 after a timeout should really be
revisited. What are you going to do if that succeeds, do the original
execute again? What if that hangs again? Are you keeping a counter? If
so, I think you are headed down the wrong path. I think you should
immediately give up, and cleanup. All the comments about possible
corruption (using signals) that Tim made not withstanding, if you have
timed out a database operation, it is probably because the operation is
flawed in its design, or because the DB is sick or way too busy.
Anything else you do (other than closing it) has the potential to make
it worse (even select 1). Closing the database connection is about the
only thing safe thing you can do on the client side, that _MIGHT_ make
it better -- primarily because you would give the DB engine a chance to
reclaim some resources, and heal itself.
Lincoln
Re: DBI use failure with DBI/DBD::Oracle on AIX 5.2
On 11/25/2004 08:03 AM, Chris Holt said:
After being prepped by experiences of others in the README.aix
file. I beleive (see below), I have a good installation. But
on running my fist test prog I appear to have a permissions
problem. This litlle ditty does not fail when run as root,
but anyone else and it aborts on the 'use DBI;'.
That is certainly an indication that you don't have permission for
something. Especially since root succeeds.
$ cat ora.pl
#!/bin/perl -w
use DBI;
use strict;
my ($dbname, $user, $passwd) = ('exua', 'remote', 'remote');
#$dbh = DBI-connect(dbi:Oracle:$dbname, $user, $passwd);
#$dbh-do(SELECT * FROM DUAL);
$
$ ./ora.pl
Can't locate loadable object for module DBI in @INC
(@INC contains: /usr/opt/perl5/lib/5.8.0/aix-thread-multi
/usr/opt/perl5/lib/5.8.0
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi
/usr/opt/perl5/lib/site_perl/5.8.0
/usr/opt/perl5/lib/site_perl .) at
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 254
BEGIN failed--compilation aborted at
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/DBI.pm line 254.
Compilation failed in require at ./ora.pl line 3.
BEGIN failed--compilation aborted at ./ora.pl line 3.
...
permissions on the directories and files under /usr/opt/perl5 appear
to be OK, at least world readable. Any ideas?
DBI.so is executable which was my first guess at the problem, make sure
the directories have executable permisson for you too.
...
364664 260 -r-xr-xr-x 1 root exua 264738 Nov 25 10:14
/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/auto/DBI/DBI.so
--
Mac :})
** I usually forward private questions to the appropriate mail list. **
Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html
Cthulhu in 2004. Don't settle for the lesser evil.
