Re: A method to asynchronously LISTEN ?
Philippe Ebersohl <[email protected]> Wed, 27 Feb 2019 11:47:48 +0100 (CET)
| Newsgroups | gmane.comp.db.postgresql.jdbc |
|---|---|
| Message-ID | <[email protected]> |
Hello, I do not think there is a need for something like conn.listenSync(). We were just intrigued about the test. In fact the current proposition should just work fine and we would like to test it. How could we have access to a postgresql-*.jdbc.jar that includes this feature ? Regards, Philippe From: "David G. Johnston" <[email protected]> To: "Dave Cramer" <[email protected]> Cc: "Philippe Ebersohl" <[email protected]>, "List" <[email protected]> Sent: Tuesday, 26 February, 2019 22:17:12 Subject: Re: A method to asynchronously LISTEN ? On Tue, Feb 26, 2019 at 12:04 PM Dave Cramer < [email protected] > wrote: On Tue, 26 Feb 2019 at 12:29, David G. Johnston < [email protected] > wrote: BQ_BEGIN The question being asked is whether executeUpdate method performs synchronous execution of the listener function queue during its execution. This after sending the command to the server and the server completing execution of the NOTIFY. This assumes that the server places the notification on the channel for pick-up immediately (which will not be the case within a transaction). While the client is, IIRC, synchronous, thus the local order of operations can be controlled, the server is asynchronous and thus this test is exposed to timing issues. Maybe we need something like conn.listenSync() that blocks until a notification payload is received on the connection...? kind of defeats the asynchronous aspect, no ? BQ_BEGIN BQ_BEGIN BQ_BEGIN BQ_END BQ_END BQ_END BQ_END You'd still want an asynchronous API for people but JavaScript introduced the "async/await" feature for a reason. In this case making it "sync" instead of coding up wait loop seems desirable. That said its quite possible I'm missing some existing feature as I haven't used this API at all. David J.