Re: Safely timing out DBI queries

2006-09-17 Thread Tim Bunce
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

Re: Safely timing out DBI queries

2006-09-17 Thread Henri Asseily
Also, rather than fork each time you need a timeout it would be nice to be able to have a single 'watchdog' process and use some form of fast IPC to tell it when to be active (passing the timeout to use and relevant session id) and when to be inactive. A pipe would be fine. But perhaps that

DBI-connect() fails

2006-09-17 Thread Madhukiran
Hi, DBI-connect() returns a NULL handle in Perl 5.6.1 if ORA-28002 is hit in Database. ORA-28002 stands for password will expire in xx days. DBI-connect() returns the db connection handle in Perl 5.8.3 even if ORA-28002 is hit in Database. ORA-28002 is just a warning as so behaviour in

Re: Safely timing out DBI queries

2006-09-17 Thread Martin Gainty
unsubscribe immediately * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in

Re: Safely timing out DBI queries

2006-09-17 Thread Alexander Foken
Read The Fine Mail headers which tell you how to do so! On 17.09.2006 13:47, Martin Gainty wrote: unsubscribe immediately * This email message and any files transmitted with it contain confidential information intended only

Re: Safely timing out DBI queries

2006-09-17 Thread Martin Gainty
where ? Martin-- * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error,

Re: Safely timing out DBI queries

2006-09-17 Thread Zhivko Ivanov Duchev
On 17.9.2006 16:21, Martin Gainty wrote: where ? Martin-- * This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If

Re: Safely timing out DBI queries

2006-09-17 Thread Sam Tregar
On Sun, 17 Sep 2006, Tim Bunce wrote: 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

Re: Safely timing out DBI queries

2006-09-17 Thread Sam Tregar
On Sun, 17 Sep 2006, Henri Asseily wrote: This is a good way for handling a few potentially long-running queries, but forking each time means that you create a new dbh each time, correct? That's impossibly slow for environments like high-volume webservers. Right. And a few long-running

Re: Safely timing out DBI queries

2006-09-17 Thread Dean Arnold
(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

Re: Problem upgrading DBI using CPAN (module test suite fails)

2006-09-17 Thread Jack Faley ( Who's going to take me serious without a laser pointer?)
On 9/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: To err is Human: Extremely effective mayhem requires the root password! On Sep 5, 2006, at 10:48 PM, Jack Faley ( The Tao of Jack ) wrote: Infact, though I did have the db software installed I did NOT have any databases cataloged or

Re: Safely timing out DBI queries

2006-09-17 Thread Sam Tregar
On Sun, 17 Sep 2006, Dean Arnold wrote: 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 ? DBIx::Timeout uses a separate

Re: Safely timing out DBI queries

2006-09-17 Thread Ron Savage
On Sun, 17 Sep 2006 10:59:48 -0700, Dean Arnold wrote: Hi Dean just swallow the signal. (I'll note that signals are conclusive proof that UNIX was developed in an era when recreational narcotics were readily available and inexpensive.) The more things change, the more things stay the

Archives, anyone?

2006-09-17 Thread Lane
Hi. Can someone please point me to a searchable archive of dbi-users. And, if you can point me to a specific reference about this problem, then I'll be just as happy as can be. I'm getting the following error: DBD::DBM::st execute failed: Storable binary image v37.49 more recent than I am

Re: New here. dbi:DBM:mldbm=Storable;f_dir=/foo/bar. Inserts when asked to update and other weirdness

2006-09-17 Thread Jeff Zucker
Lane wrote: my $dbh = DBI-connect('dbi:DBM:mldbm=Storable;f_dir=./foo'); Yes, there does appear to be a bug in DBD::DBM update when the key field is updated. I'll look into it. In the meantime, since you said that you are only prototyping, you can use Temporary tables which are not effected

Re: New here. dbi:DBM:mldbm=Storable;f_dir=/foo/bar. Inserts when asked to update and other weirdness

2006-09-17 Thread Lane
On Sunday 17 September 2006 23:09, Jeff Zucker wrote: Lane wrote: my $dbh = DBI-connect('dbi:DBM:mldbm=Storable;f_dir=./foo'); Yes, there does appear to be a bug in DBD::DBM update when the key field is updated. I'll look into it. In the meantime, since you said that you are only

Re: Archives, anyone?

2006-09-17 Thread Owen
On Sun, 17 Sep 2006 22:16:12 -0500 Lane [EMAIL PROTECTED] wrote: Hi. Can someone please point me to a searchable archive of dbi-users. You can search Google Groups perl.dbi.users Owen