Urgent ... Weird behaviour when incrementing system variable

I had the doubles with:

  • {:SerialNumber} see beginning of this post
  • {:GLOBAL SETTING:SerialNumber}
  • But maybe also with {:SETTING:SerialNumber} I don’t remember.

I think what is really happening here is a race condition.

I don’t get doubles with this, but I am probably not fast enough with switching to make it happen:


I have a feeling that if 2 Terminals (not even necessarily Sessions) were to pull up a Ticket for Payment, enter the value for Payment, then both simultaneously click a Tender button (ie. Cash) at the same time, they COULD read the same value from the DB, increase it (maybe even causing a skip), read the new value for Tag, and possibly produce a double.

It might be the case when using actual Terminals (not Sessions) that DB reads/updates might be queued by the Messaging Service, so this does not happen. No idea.


How to fix this?

If the above is all TRUE, I don’t think even using Script and Report could prevent the problem if 2 Sessions (or actual SambaPOS Terminals) were to receive payment so close to the same time.

The only thing I can think of would be to divide the Serial Numbers by Terminal so that they have their own counters (ie. prefix the SerNum with Terminal Name), in which case, they would never be reading/updating the same Program Setting from one Terminal to another.

Don’t waste time with that, I am sure that’s not it.
On top, the doubles are not “double”, there are more like that: (if neighter closes their SambaPOS)

Sometimes though I got the impression that “SambaPOS waiter 2” resymchronised with database but I cannot be sure because with all the modifications I’ve done, I’ve asked them to stop/start SambaPOS a lots of time

The [quote=“QMcKay, post:142, topic:15062”]
How to fix this?

If the above is all TRUE
[/quote]

It cannot be true, I got a lot of double and I can tell you that really few few were done the same minute, and fewer within seconds.

Deleted DOUBLE POST … wtf is with the double POSTING today ??? … LOL :stuck_out_tongue:

1 Like

With Update Type set to Update, It works unless both click the same exact time even 1/10 of second different I only get double 20%.

So, Update Type: Increase has problem with caching so, never know when it gonna sync/re-read from database.

Maybe we can cause enough of a delay by splitting to 2 Rules.

##Rule #1

  • Update the value.
  • Send the value to Rule #2 as Command Value.

##Rule #2

  • Read the Command Value
  • Read the DB value.
  • Compare the 2 values using Action Constraints.
  • if values are equal:
  • Tag ticket with Command or DB Value + 1
  • Update DB with + 1
  • Print Ticket
  • if values are not equal:
  • Tag ticket with Value
  • Print Ticket

Seems crazy.

I have an idea.
Call Script with loop delay ramdom. Just split it prob. delay the same amount of time.

I think Update Setting with Update type works but:

It depends on what value you give to that action.

If you give { Global Setting or Setting or just :SerialNumber }

How do you know for sure that this ^ is read from DB and not from a variable?

Race conditions might produce error. OK.

But in this case. It is not a race condition problem

Race condition inplies a read/write to database.

Our problem is that somewhere there is no reading/write to DB where there should be.

If you re read my step. You will see I click Show Message with the value of {SETTING:XXX} and it show correct number. Only wrong number happen after using Update Program Setting with Update Type: Increase.

I repet the step like before but now I can’t reproduce it after change to Update Program Setting with Update Type: Update.

1 Like

The yesterday night behaviour.

In yellow (down) : the first ticket settled by Grecia (waitress 2)
In Yellow (up) : The last ticket settled by Celia (waitress 1)

When both working, the doubles

Definitevely no race condition.

… double post AGAIN …

race conditions … LOL :wink:

Yes, and that is exactly what I am implying.

Maybe, but that could manifest itself as a race condition.

I will not deny that Update Type:Increase appears to be broken when you update a value then subsequently read it.

But even that ^ could be a race. It doesn’t mean the value wasn’t updated, it just means the subsequent READ was too fast.

Or are you claiming otherwise? Are you saying that Increase is broken? How do you know for sure?

I think I did yesterday on Server (not RDP) so, i don’t think multi session too. It just pure Update Type Increase

  1. Trigger Update Program Setting with Increase (let say 20 now)
  2. Open SSMS to change the value back to 10
  3. Trigger Update Program Setting with Increase again it should be 21 now.

I think the value we pass to the
Update Program Setting
action is not read from DB.

No matter if Increase or Update type.


While I think that what you mean is:

Update Setting

  • It is read from the db (no need to check if DB/table/record is locked)
  • incremented
  • update into the db (db/table/record locked)

here impossible to have a race condition

Tagged

  • It is read from DB (no need to check if locked)

maybe race condition, the value is maybe not updated yet, which - if the actions are executed in order - would make Ms SQL server useless.

I know for a fact I use this method with 3 terminals all windows tablets running sambapos and connected to database via connection string all Wi-Fi connected. Never once had it done this. I still think it’s unique to the terminal setup your using. I’m not saying it’s not a bug it certainly may be.

The event I use though is ticket created

It wouldn’t hardly ever be read from the DB. Increase we pass “1”, Update we pass “whatever” - it could be a value read from the DB or it could be the word “blah”.


For Increase we pass:

  • The Setting Name
  • The Setting Value (1)
  • The Setting Type

The Setting Name is the Name in the ProgramSettingValues Table.
So if using Setting Type Increase in this blackbox

Of course we have to expect that it will take the current value of the name and it will take it from ProgramSettingValues table; add Setting value (1) and Update that table.[quote=“QMcKay, post:157, topic:15062”]
Update we pass “whatever”
[/quote]

That whatever must be read from DB.

I get what you’re saying now.

Are you implying it is not reading the Value from the DB for the associated Setting NAME? Or that it is not updating it (when using Increase Update Type).

That might be the case but I don’t thing so, I think the value we use to tag; to update; (not to increase) is not read from db, it is an independant variable for each SambaPOS instances.

That value is related to {SETTING:SerialNumber}

I might be wrong but that is what I feel.