Zugg Software :: View topic - [2.20] Variables reverting back to previous values.

Magician Joined: 23 Nov 2004 Posts: 364

The problem happens with my settings as well, so I'll send you my package too. It'll be called chris74269.pkg and the alias/variable that always revert are from 'znote add blah blah' ect and the @notes variable.

Posted: Tue May 06, 2008 3:05 am

Thanks Chris, I got your files and will test it tomorrow and let you know what I find.

Posted: Tue May 06, 2008 1:42 pm

Posted: Tue May 06, 2008 6:03 pm

Yep, I can reproduce it now. And it's the same as in the files that Caled sent to me. I'll work on this today and try to get it fixed.

Posted: Tue May 06, 2008 7:35 pm

OK, Finally! I found the problem. This is actually a very stubborn and tricky bug. The problem lies in the fact that CMUD keeps multiple cache values for speed improvements. Each setting record has a cached string containing the "value" of the setting (like the value of a variable). CMUD uses this cache when it can to avoid doing a database query, especially since the Value field is a Memo (Blob), which is slower to access than something simpler like an integer field.

When the database hash table was added, the variable gets a pointer to this hash table. CMUD tries to avoid converting the hash table into a full string value (like key1=value1|key2=value2...etc). So the hash table has it's own cached string "value". When you do #ADDKEY, CMUD adds the key=value to the hash table, and marks the hash table as "changed". But the hash table has no knowledge of the database where variables are stored, so the database can't tell that the value field has changed. CMUD doesn't want to update the value field, because that would mean converting the hash table to a string value that can be stored.

So CMUD just marks it as "changed" and waits until the database is actually saved, either in the background, or when CMUD exits.

In the background saving thread, it loops through the database to see what has changed. When it sees a Variable, it also checks the hash table to see if it was changed. If the hash table was changed, then the string value is computed and stored into the database and the database record is then marked as changed, which is then saved to the database file.

So, it's complicated. All because CMUD is trying to maintain high performance and not convert a hash table into a string value unless absolutely necessary.

What was the bug? Well, in the background save routine it was checking the hash table to see if it was "changed". But in some cases (like the one in this post), the hash table had already updated it's internal cache, so it wasn't marked as changed anymore. This can happen whenever you access the value. In the case of Caled's files, he was doing a #SHOWDB @notes. In the case of the example above, in step (8) you were doing a "#say @temp". This was forcing the hash table to convert to a string, so the hash table was no longer marked as "changed".

But the hash table string value was not being saved to the internal database. So the internal database cache still had the previous value of the string. And when the background save routine checked for a "changed" record, this variable was no longer marked as changed.

So it was a case with two string caches that were getting out of sync. As soon as CMUD was accessing the string value, it was getting updated internally, but that was too late in the background save routine to get the new value saved to disk.

I probably didn't explain that very well. Yes, it's probably a bad idea to have two different caches of the same string data, but that's what happens sometimes with modular code. The StringHash class has no connection to the Database that maintains it's own cache. It's all very overly complicated and if I think of a better way to do it in the future, then I'll mess with it. But right now it works 99% of the time, and hopefully this bug fix is the last problem in the hash table code.

And yes, this only happened with variables actually marked as Record since those are the only ones that maintain the hash table cache. And it only happened if you did something to display the variable (like in step 8) before you exited.

Anyway, fixed for v2.24.

Posted: Thu May 08, 2008 1:14 am

Confirmed totally fixed for 2.24.

Thanks!

Posted: Thu May 08, 2008 1:15 am

Woohoo! finally ;)

Posted: Thu May 08, 2008 5:55 am

Seriously, it had more lives than a cat. Thanks for persevering.