Re: [Ruby-DBI-devel] PGconn::exec vs. PGconn::async_exec benchmark

[Florian G\. P. <fg...@ph...>]

On Fri, May 09, 2003 at 10:19:30PM +0200, Michael Neumann wrote:
> There's currently no other database module that has such pseudo-async
> methods (or I am simply not aware of it).

I just checked - the mysql module seems to have no support.
The "old" (oracle 7) compatible module doesn't seem to have support either
(altough I'm not sure with oracle... the oci interface is more complex than
the mysql or postgres interface, so I might have misread the code)

But there is a oci8 interface for ruby (http://www.jiubao.org/ruby-oci8/).
This also includes a DBI Driver (DBD::OCI8). This driver implements the flag
"NonBlocking" to let the user decide indicate which behaviour he prefers.

-----------------------------------------------------------------
class Driver < DBI::BaseDriver
...
...
def connect( dbname, user, auth, attr )
    handle = ::OCI8.new(user, auth, dbname, attr['Privilege'])
    handle.non_blocking = true if attr['NonBlocking']
    return Database.new(handle, attr)
  rescue OCIException => err
    raise raise_error(err)
end
...
...
-----------------------------------------------------------------

> I've come to the conclusion that the best probably is to introduce a
> "pg_async_exec" flag and then dependend on this flag execute either
> async_exec or exec in the Statement#execute method.

See above. Since there is a oracle DBD, and it has this kind of flag, I
think it would be best to name it the same ("NonBlocking"). Come to think if
it I also believe, that "NonBlocking" better describes what it actually
does, since from a users point of view exec() and query() calls are still
synchronous - they just don't influence other threads.


> Note that all other
> methods still call exec. As those calls usually issue COMMIT, ROLLBACK
> or BEGIN statements, I don't think there's a big differece when using 
> async_exec.  But of course I may be wrong. Or should I use everywhere 
> the async method when the flag is set?

IMHO you need to use for every query that may potentially take a long time.
Remember, when a query is issued using the "synchronous" call
(exec instead of async_exec), _all_ _other_ _threads_ are blocked until
the query completes. 

"BEGIN" (and possibly "ROLLBACK") are usually quite fast, I guess. But
"COMMIT" could take quite a time of you did a lot of inserts and updates in
the transaction (or so I think).

greetings, Florian Pflug