Correct Server Saving Character information All the Time

[aknorjaden]

PROBLEM:
When fixing the attributes-not-getting-saved problem a few weeks ago, I inadvertently introduced a non-optimal problem into the server code when logging in and using the game. The problem is the worst when all skills are trained on the character and was noticed when I used the new giveallskills GM command I recently added. It took minutes and minutes to "save" the character data to the database on a login. Seems to do it that long at other times, but might be inconsistent. The problem lies with the

It seems to do this several places on login and is always making the call Character::SaveCharacter(), so we need to search for where this is being called and evaluate how to minimize the impact of doing this saving. We only need to save this stuff when necessary.

STEPS TO REPRODUCE:

1. Start the server and the client, then log in one of your characters.
2. Issue the new giveallskills GM command or not, it's your choice, but that command will take quite a while to complete (another possible "bug" perhaps)
3. Notice that a few times during the login process, you'll see messages in the server console saying "Character::SaveCharacter(): Saving all character info and skill attribute info to DB for character XXXXXXX..."

WORKAROUND:
There is no way to workaround this problem as it is applied to every character at the points where the saving happens. Only way to minimize it is to minimize the number of skills trained by the character. This problem is the worst after one has run the giveallskills command as this trains ALL skills to the character and ends up taking minutes to save the character to the Database upon login and logoff.

PROPOSED SOLUTION:
After some consideration, I believe I have a good solution. InventoryItem class should have a "dirty" flag that indicates something about it has been CHANGED since the last time it was written to the database. Whenever some other object invokes InventoryItem::SaveItem(), it should check to see if this dirty flag is set and if so, proceed with write to database, otherwise, ignore. This should ensure that even if other objects are looping through large caches of items during a bulk save-off operation, only the ones that have been changed get committed to the database. One can imagine that with a server running quite a long time will see many objects get changed and require writing to the database so this solution should also be coupled with the caveat that at some point in the future, we'll need random periodic saves of modified objects to the database in order to minimize the sheer amount of time it will take for ALL changed objects to get saved when the server is shutdown. For now though, we can just implement the dirty flag in InventoryItem.

[positron96]

We need to check if SaveCharacter calls are needed where they are called, and probably reduce number of calls. Also, partial fix would be to create AttributeMap with mChanged=false, so synced with DB maps do not get saved.

[zhyrohaad]

this has been fixed via major code rewrite.