On 11/03/2014 07:05 AM, Scott Harrington wrote: > This avoids the need for a Future, and avoids the client having to > loop/sleep until done.
A Future is the logical way to represent an asynchronous operation in Java. Why implement something else that doesn't fit into existing libraries and tools when there's already a standard interface? If you're breaking outside the stock JDBC model and thinking asynchronously, then using the existing Java APIs for asynchrony makes sense to me. In terms of looping until done ... what we really need is a reliably non-blocking PGConnection.consumeInput() so apps can call that in their main loops, or via a helper thread. Then we'd be able to add async notification callbacks too. To do that we need to make PGstream use a java.nio.Channel instead of a java.net.socket . -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
