NOTIFY

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

NOTIFY

Greg Rychlewski (LCL)

Hi,

 

I’m considering using NOTIFY to let my application react to changes in a table. If I only send the channel name without a payload, could I run into this issue:

 

  1. The table is updated and a notification is sent to my app
  2. My app reads the table, but hasn’t sent acknowledgement of the notification yet
  3. The table is updated again, but the notification gets dropped because it’s the same as (1), which hasn’t been acknowledged by the app

 

If this happened then there would be new data in my table but my app wouldn’t read it until the next time there was an update.

 

Thanks

This email message is confidential, may be legally privileged and is intended for the exclusive use of the addressee. If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained. Please inform us of the delivery error by return email. Thank you for your cooperation.

Le présent message électronique est confidentiel et peut être couvert par le secret professionnel. Il est à l’usage exclusif du destinataire. Si vous recevez ce message par erreur ou si vous n’en êtes pas le destinataire prévu, vous devez détruire le message et toute pièce jointe ou copie et vous êtes tenu de ne pas conserver, distribuer, divulguer ni utiliser tout renseignement qu’il contient. Veuillez nous informer de toute erreur d’envoi en répondant à ce message. Merci de votre collaboration.

Reply | Threaded
Open this post in threaded view
|

Re: NOTIFY

David G Johnston
On Mon, Sep 28, 2020 at 3:35 PM Greg Rychlewski (LCL) <[hidden email]> wrote:

Hi,

 

I’m considering using NOTIFY to let my application react to changes in a table. If I only send the channel name without a payload, could I run into this issue:

 

  1. The table is updated and a notification is sent to my app
  2. My app reads the table, but hasn’t sent acknowledgement of the notification yet
  3. The table is updated again, but the notification gets dropped because it’s the same as (1), which hasn’t been acknowledged by the app

 

If this happened then there would be new data in my table but my app wouldn’t read it until the next time there was an update.


I don't understand where you are getting point 2 from - the pub/sub model doesn't require subscribers to acknowledge the notifications.

For point 3 you seem to have mis-read the NOTIFY documentation, which states:

"If the same channel name is signaled multiple times with identical payload strings within the same transaction, only one instance of the notification event is delivered to listeners."

The part about "within the same transaction" solves your concurrency concern, and doesn't say anything about acknowledgements.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: [EXT] Re: NOTIFY

Greg Rychlewski (LCL)

Thank you.  For number 2 my wording was poorly chosen, but I was thinking about this statement in the documentation:

 

There is a queue that holds notifications that have been sent but not yet processed by all listening sessions.”

 

I’m not sure how the queue is notified that the notification has been processed. I was referring to that as the “acknowledgement”.

 

From: "David G. Johnston" <[hidden email]>
Date: Monday, September 28, 2020 at 8:07 PM
To: "Greg Rychlewski (LCL)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: [EXT] Re: NOTIFY

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

On Mon, Sep 28, 2020 at 3:35 PM Greg Rychlewski (LCL) <[hidden email]> wrote:

Hi,

 

I’m considering using NOTIFY to let my application react to changes in a table. If I only send the channel name without a payload, could I run into this issue:

 

  1. The table is updated and a notification is sent to my app
  2. My app reads the table, but hasn’t sent acknowledgement of the notification yet
  3. The table is updated again, but the notification gets dropped because it’s the same as (1), which hasn’t been acknowledged by the app

 

If this happened then there would be new data in my table but my app wouldn’t read it until the next time there was an update.

 

I don't understand where you are getting point 2 from - the pub/sub model doesn't require subscribers to acknowledge the notifications.

 

For point 3 you seem to have mis-read the NOTIFY documentation, which states:

 

"If the same channel name is signaled multiple times with identical payload strings within the same transaction, only one instance of the notification event is delivered to listeners."

 

The part about "within the same transaction" solves your concurrency concern, and doesn't say anything about acknowledgements.

 

David J.

 

This email message is confidential, may be legally privileged and is intended for the exclusive use of the addressee. If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained. Please inform us of the delivery error by return email. Thank you for your cooperation.

Le présent message électronique est confidentiel et peut être couvert par le secret professionnel. Il est à l’usage exclusif du destinataire. Si vous recevez ce message par erreur ou si vous n’en êtes pas le destinataire prévu, vous devez détruire le message et toute pièce jointe ou copie et vous êtes tenu de ne pas conserver, distribuer, divulguer ni utiliser tout renseignement qu’il contient. Veuillez nous informer de toute erreur d’envoi en répondant à ce message. Merci de votre collaboration.

Reply | Threaded
Open this post in threaded view
|

Re: [EXT] Re: NOTIFY

David G Johnston
Same page:

"Secondly, if a listening session receives a notification signal while it is within a transaction, the notification event will not be delivered to its connected client until just after the transaction is completed (either committed or aborted)."

I can see where "processed" can be misleading but it is referring to an implementation detail within the depths of the inter-session communications.  At the application layer if your application client connection has been delivered the notification your session is considered to have processed it and will, apparently, report that delivery to the application client connection back to the queue.

Maybe: "There is a queue that holds notifications that have been sent to, but yet delivered by, all listening sessions."  Though we'd need to ensure that the target of the delivery (i.e., the application connection) is clear...

David J.


On Mon, Sep 28, 2020 at 5:33 PM Greg Rychlewski (LCL) <[hidden email]> wrote:

Thank you.  For number 2 my wording was poorly chosen, but I was thinking about this statement in the documentation:

 

There is a queue that holds notifications that have been sent but not yet processed by all listening sessions.”

 

I’m not sure how the queue is notified that the notification has been processed. I was referring to that as the “acknowledgement”.

 

From: "David G. Johnston" <[hidden email]>
Date: Monday, September 28, 2020 at 8:07 PM
To: "Greg Rychlewski (LCL)" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: [EXT] Re: NOTIFY

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

On Mon, Sep 28, 2020 at 3:35 PM Greg Rychlewski (LCL) <[hidden email]> wrote:

Hi,

 

I’m considering using NOTIFY to let my application react to changes in a table. If I only send the channel name without a payload, could I run into this issue:

 

  1. The table is updated and a notification is sent to my app
  2. My app reads the table, but hasn’t sent acknowledgement of the notification yet
  3. The table is updated again, but the notification gets dropped because it’s the same as (1), which hasn’t been acknowledged by the app

 

If this happened then there would be new data in my table but my app wouldn’t read it until the next time there was an update.

 

I don't understand where you are getting point 2 from - the pub/sub model doesn't require subscribers to acknowledge the notifications.

 

For point 3 you seem to have mis-read the NOTIFY documentation, which states:

 

"If the same channel name is signaled multiple times with identical payload strings within the same transaction, only one instance of the notification event is delivered to listeners."

 

The part about "within the same transaction" solves your concurrency concern, and doesn't say anything about acknowledgements.

 

David J.

 

This email message is confidential, may be legally privileged and is intended for the exclusive use of the addressee. If you received this message in error or are not the intended recipient, you should destroy the email message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained. Please inform us of the delivery error by return email. Thank you for your cooperation.

Le présent message électronique est confidentiel et peut être couvert par le secret professionnel. Il est à l’usage exclusif du destinataire. Si vous recevez ce message par erreur ou si vous n’en êtes pas le destinataire prévu, vous devez détruire le message et toute pièce jointe ou copie et vous êtes tenu de ne pas conserver, distribuer, divulguer ni utiliser tout renseignement qu’il contient. Veuillez nous informer de toute erreur d’envoi en répondant à ce message. Merci de votre collaboration.

Reply | Threaded
Open this post in threaded view
|

Re: [EXT] Re: NOTIFY

David G Johnston
On Mon, Sep 28, 2020 at 5:48 PM David G. Johnston <[hidden email]> wrote:
Maybe: "There is a queue that holds notifications that have been sent to, but yet delivered by, all listening sessions."  Though we'd need to ensure that the target of the delivery (i.e., the application connection) is clear...

Proposed patch sent to -hackers:


David J.