p
l
e
a
s
e
d
o
n
o
t
w
e
a
r
o
u
t
y
o
u
r
e
n
t
e
r
k
e
y
----- Original Message -----
From: Rob Bloodgood <[EMAIL PROTECTED]>
To: Fletch <[EMAIL PROTECTED]>
Cc: POE <[EMAIL PROTECTED]>
Sent: Monday, September 17, 2001 9:34 PM
Subject: RE: Non-blocking DBI?
> > >>>>> "Rob" == Rob Bloodgood <[EMAIL PROTECTED]> writes:
> >
> > Rob> Does anybody know of a way to run a non-blocking DBI query?
> > Rob> Non-portable is ok with me, if it works with Oracle! :-)
> >
> > I've heard rumors that there's been investigation into
> > some form of asynchronous DBI calls, but I don't think anything's been
> > done yet. What I've been doing is using POE::Wheel::Run to start up a
> > few seperate helper processes which make all the DBI calls. There's a
> > queue that has a next() method that returns the next available helper
> > in a round robin fashion. The helper is just a while loop that reads
> > requests, parses out the relevant data (split /\|/, $req), executes a
> > pre-prepare'd statement, and then prints the result back to the main
> > process.
> >
> >
> > Not exactly what you're looking for, but it's fairly easy to
> > implement and will work with any backend database.
>
> Sounds interesting, but I'll be honest... my FEAR level just went up.
>
> OK, please confirm if that I get you correctly:
>
> Your idea is to
> spawn a seperate process
> for running DBI
> that sends an event
> to the parent process
> after a dbi call has finished?
>
> Wow...
> that sounds so great
> except
> that
> in my case
>
> it's (almost) guaranteed to fail
> critically
> as soon as I need it to work.
>
> <sigh>
>
> Unless you (or anybody else)
> has some bulletproof, production ready, survived-rollout!
> code
> for managing this?
>
> <crosses fingers>
>
> L8r,
> Rob
>
> #!/usr/bin/perl -w
> use Disclaimer qw/:standard/;
>
>
