PostgreSQL listen/notify and the method stack

Nick Renders omnis1 at arcict.com
Wed Nov 29 13:59:31 UTC 2023


For anyone who's interested, Omnis Support confirmed that the $notify method will interrupt the method stack. So be mindful if your $notify has a lengthy job to do. It might be interrupting code that you don't want to hang for too long, like for instance a database transaction with locked records.

Omnis Support also confirmed that the $notify method itself will not be interrupted when a new NOTIFY is received. Instead, they are queued and will be handled after the current $notify has finished.

An enhancement request has been made to add a feature so that we can decide whether a $notify should interrupt the current method stack or be queued: ST/*A/169 .

As a a workaround, I now set a timer in the $notify method with the option $queueevent = kTrue. That way, the $notify interruption is minimal, and the actual code is executed in the $timer method of the Timer object at the end of the method stack.


Nick Renders


On 23 Nov 2023, at 23:13, Doug Easterbrook wrote:

> You can ask omnis if you want to get the total scoop.
>
> There are two types of timers.   Ask omnis to get the definitive answer
>
> ------------
> Doug Easterbrook
> Arts Management Systems Ltd.
> doug at artsman.com
>
>> On Nov 23, 2023, at 8:54 AM, Nick Renders <omnis1 at arcict.com> wrote:
>>
>> Hi Doug,
>>
>> I don't think the call to a $notify method is just added to the method stack. In my test, it interrupts the current method. I can send you a little demo library, if you like.
>>
>> Thanks for the tip on keeping a list of notifications. I was thinking about having the $notify schedule a timer in order to queue the action, but this might be a more elegant solution.
>>
>>
>> Nick Renders
>>
>>
>>> On 23 Nov 2023, at 14:29, Doug Easterbrook wrote:
>>>
>>> The other thing you can do if you are concerned is make a listen notify handler.  I have an example in the pgsqldam object in the sample code from  euromis
>>>
>>> If you get a notify,  then add it to a list of pending calls.   When you’d stack has diminished. Call a routine to process the pending notifies in the list and clean the list out
>>>
>>> That make notify nothing more than add line to pending list so it pretty much eliminates potential interaction with other code
>>>
>>> I don’t think you should worry about, but then I don’t know how much work you are doing in the notify
>>>
>>> ------------
>>> Doug Easterbrook
>>> Arts Management Systems Ltd.
>>> doug at artsman.com
>>>
>>>>> On Nov 23, 2023, at 6:38 AM, Doug Easterbrook <doug at artsman.com> wrote:
>>>>
>>>> As far as I understand the timer is popped on the stack
>>>>
>>>> It’s the same as background workers
>>>>
>>>> So it eventually gets executed as the omnis stack winds down
>>>>
>>>> Just make sure your variable scope is right and you won’t have problems
>>>>
>>>>
>>>> All Timers act the same way
>>>>
>>>> ------------
>>>> Doug Easterbrook
>>>> Arts Management Systems Ltd.
>>>> doug at artsman.com
>>>>
>>>>> On Nov 23, 2023, at 2:48 AM, Nick Renders via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
>>>>>
>>>>> Hello fellow Omnis-Potents,
>>>>>
>>>>> I have noticed that when implementing the $listen and $notify methods of the PostgreSQL DAM, the $notify method actually interrupts the current method stack. So when Omnis is executing a certain method, the notification will cut in, execute the $notify method, and return to the previous method where it left off. At least that is what I've come to understand after doing some tests.
>>>>>
>>>>> I'm not very comfortable with the $notify method interrupting any possible method at any possible time. Has anyone encountered this before? Does anyone have any good tips and/or tricks on managing listeners/notifiers?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Nick Renders
>>>>> _____________________________________________________________
>>>>> Manage your list subscriptions at https://lists.omnis-dev.com
>>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com


More information about the omnisdev-en mailing list