NAS and 2 nav timers

Evert-Jan

Hi All,

I have a problem with one NAS working with multiple timers.
Let's start with explanation of my situation.
Codeunit 1:

IF CGNASStartedinLoop = FALSE THEN
    CASE Parameter OF
      'OSYNCH','JOBQUEUE':
        BEGIN
          // ...
          CODEUNIT.RUN(CODEUNIT::"Job Queue Dispacher"); //starts navtimer1
        END;
      'MSFSYNC' : CODEUNIT.RUN(CODEUNIT::"Data Sync. Management"); //FLEX.n //starts navtimer2
    END;

The NAS is started with 2 options: JOBQUEUE and MSFSYNC. So, from the NAS the cu Job Queue Dispatcher is started and also cu Data Sync. Management. Both codeunits are single instance and work with a nav timer. the cu Data Sync. Management is running very often. 100 times per second or so. Some more code from the timer trigger in cu Data Sync. Management:

Timer.Enabled := FALSE;
IF CODEUNIT.RUN(CODEUNIT::"Process Sync. Queue") THEN;
Timer.Enabled := TRUE;

So, now my problem.
When navtimer1 is executing some code and does a modify on a table, immediately navtimer2 reports (via the event viewer) the well-known long error that a transaction is going on and the NAS is killed.
When I add a commit:

Timer.Enabled := FALSE;
COMMIT;
IF CODEUNIT.RUN(CODEUNIT::"Process Sync. Queue") THEN;
Timer.Enabled := TRUE;

then the error disappears.

It seems that both processes interfere with each other.
May be I am committing the data from the other codeunit running via navtimer1.
I'm afraid this isn't a good solution.
Any suggestions?

einsTeIn.NET

Evert-Jan wrote:

May be I am committing the data from the other codeunit running via navtimer1.

No, afaik, transaction ends when the timer event trigger ends.

Evert-Jan

I hope you are right, but can you explain why the error pops up when I remove that commit?

pduck

Why not preventing the error? If those are single instance codeunits you can check the timer.enabled property of the opposite codeunit. If it is true you can run your code, if not then the other code is running and you should wait or skip.

einsTeIn.NET

I've never seen such kind of problem so far. I also worked with two timer controlled single instance codeunits and I didn't get such problems. But in my case timer wasn't fired that often. Maybe it has to do with it.

It's very weird that the error message disappears when COMMIT is the first statement. At that point in time there should be no transaction started and thus no data modification to be commited.

When you try to switch off the timer in the other codeunit then you will still have a little period of time where this error message could occur. If you couldn't find another way you should think of calling both functionalities by one timer.

I would expect when you have two single instance codeunits then NAV should create to instances of the timer "class". But maybe there is a problem with the non existing multithread functionality of NAV. Perhaps someone with a better technical background of how is NAV working in detail could explain what is happening in such a case...

Evert-Jan

einsTeIn.NET wrote:

It's very weird that the error message disappears when COMMIT is the first statement. At that point in time there should be no transaction started and thus no data modification to be commited.

I agree

einsTeIn.NET wrote:

When you try to switch off the timer in the other codeunit then you will still have a little period of time where this error message could occur.

I do not understand this sentence...

einsTeIn.NET wrote:

If you couldn't find another way you should think of calling both functionalities by one timer.

Actually, I think of using an extra NAS. But then, the customer feels the pain.

einsTeIn.NET

Evert-Jan wrote:

einsTeIn.NET wrote:

When you try to switch off the timer in the other codeunit then you will still have a little period of time where this error message could occur.

I do not understand this sentence...

I mean if the problem depends on the rate the event trigger is fired then it will still be possible that the error message appears. (To be honest it's possible regardless of the rate, but it's more unlikely when it doesn't depend on the rate.) To switch off the timer in the other codeunit will last a few milliseconds and if the event trigger is fired 100 times per second then it's not unlikely that the trigger is fired right before you want to switch it off.
Although I still think both triggers should be in a seperate transaction and shouldn't interact with each other.

Evert-Jan wrote:

Actually, I think of using an extra NAS. But then, the customer feels the pain.

Also a possible solution. But as you mentioned you have to buy another NAS license.