Re: (long) improving async support in psycopg

Daniele Varrazzo wrote:
> On Wed, Mar 24, 2010 at 3:38 AM, Jan Urbański <[email protected]> wrote:
>> On 23/03/10 01:38, Jan Urbański wrote:
> 
>> I won't bother you with the details of how an async connection building
>> procedure could look like, I just want to raise one last issue. The
>> connection class issues a couple of queries, like SHOW client_encoding or
>> SHOW default_transaction_isolation. These are issues synchronously and there
>> is no control over them. That would even be OK, hopefully an application
>> would not create and close lots of connection during it's lifetime. The bad
>> thing is the BEGIN query that gets issued synchronously and even less
>> convenient is that COMMITs are synchronous, and these could take some time
>> on systems with a certain configuration.
> 
> I was wondering if it wouldn't be better to have "async" as a
> connection characteristic (a `psycopg2.connect()` parameter) instead
> of as a parameter of the single query executions. This way the driver
> could performed these steps in asynchronous fashion too. Also the
> issues arising by mixing up sync/async operation would disappear.

That might make sense. Although then you can't use the same connection
for both sync and async things, so if in your software you sometimes
want to just execute a simple blocking query and then do na asynchronous
one you would have to open two separate connections.

You could argue that an application that uses the async interface will
not want to block ever (that's certainly the case with my Twisted PG
module, I would never use sync execution there). But is it worth it to
impose that limit? It's easy enough to just disallow running anything
while the connection is processing an async query.

Jan

_______________________________________________
Psycopg mailing list
[email protected]
http://lists.initd.org/mailman/listinfo/psycopg