H.Merijn Brand wrote:
On Thu 26 Aug 2004 10:04, Tim Bunce <[EMAIL PROTECTED]> wrote:

On Thu, Aug 26, 2004 at 12:02:19AM -0500, david nicol wrote:

In the recent roadmap announcement, Tim Bunce wrote:


=head2 Other Enhancements

* Support non-blocking mode for drivers that can enable it in their
client API.

I have just startedworking with DBI but I'm doing something that would benefit from a non-blocking mode.

I would like a $sth->ready() function, which would start false but
become true (or throw errors when RaiseError is set) when there is
at least one whole row available to fetch, and a $sth->done() function
to indicate that there is nothing left to fetch.

We would all like many things but have to settle for what's practical.

The APIs of all the main databases which offer a non-blocking mode
(which includes at least ODBC and Oracle OCI) need to be studied first
to ensure that any DBI API design is workable for them.

We might as well start that now...

Can driver authors, and anyone else interested, please reply with a
short summary of the way non-blocking mode works for 'your' database.
Including URLs to relevant docs would be a *big* help.

After that there are deep and non-trivial issues about how non-blocking
mode would interact with the DBI dispatcher and DBI.pm library code.
But those issues can wait.


DBD::Teradata has async support via driver-specific methods/attributes:

my @dbhs = ();
my @sths = ();

...connect N sessions, storing handles in @dbhs...

foreach (@dbhs) {
        push @sths, $_->prepare('insert into table values(?,?,?)',
                { tdat_nowait => 1 });
}

foreach (@sths) {
        $_->execute([shift @paramtuples]);
}

while (params to load) {
        @avails = $drh->tdat_FirstAvailList([EMAIL PROTECTED], $timeout);

        foreach (@avails) {
                $rc = $sths[$_]->tdat_Realize();
                $sths[$_]->execute([shift @paramtuples]);
        }
}

The API also supports including filehandles in the list passed to
tdat_FirstAvailList, in order to handle other async I/O events.

While this handles async execution, esp. in support of multiconnection
operations relevant to Teradata's parallel nature,
it doesn't really handle async completion notification, and
I'm not certain there's a clean, DBMS-independent way to support
that without using timers, signals, or threads, all of which
may be problematic.

Also, in many (most?) instances, driver support for Perl threads
may obviate the need for an async API; in fact, I'd prefer to see
driver developers focus first on thread support, since that doesn't
really require any API definitions, and provides much the same
capability. Perhaps DBI layer enhancements to support sharing
handles between threads would be useful as well.

Dean Arnold
Presicient Corp.

Reply via email to