From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Timing of notice delivery |
Date: | 2011-02-02 00:31:50 |
Message-ID: | 6364.1296606710@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> In other words, all on one thread, all on one connection:
> -- setup
> Execute LISTEN on the connection.
> conn.setAutoCommit(false);
> -- each transaction
> execute statements which fire triggers which NOTIFY.
> conn.commit();
> conn.getNotifications();
> Can I count on all notifications triggered during a transaction
> being delivered in the last step?
The backend will deliver all such notifies after returning the COMMIT's
command-complete response message, but before it delivers ReadyForQuery.
If JDBC waits for ReadyForQuery before believing the operation is
complete, you should see them reliably.
I believe that the situation for incoming notifies from other sessions
is a bit less predictable, though --- it looks like those can get sent
*after* ReadyForQuery, even if they arrived beforehand.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-02-02 00:49:12 | Re: Timing of notice delivery |
Previous Message | Oliver Jowett | 2011-02-02 00:16:49 | Re: Timing of notice delivery |