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

[Michael N. <mne...@nt...>]

On Sat, May 10, 2003 at 04:12:24AM +0200, Florian G. Pflug wrote:
> 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.

Yes, this flags to be the same as the async_exec method in Pg. I agree
with you that we should reuse this flag. 

OCI8 disable NonBlocking by default. We should do the same for DBD::Pg. 

> > 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.

I'd even like "Blocking" as flag more, because when NonBlocking=false you have 
to think a bit more if it's now blocking or not :-) (at least this is the case 
for my lazy mind).
But luckily it's not the case that one would use this flag very often in a
program.

> > 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. 

No problem. So I'll use it for every statement.

> "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).

Thanks for your comments.


Regards,

  Michael