Let's say I have a server, where clients who connect are constantly updating their inventory.
I could simply save the changes in to the database after an item has been updated, or I could update the whole inventory after the client leaves the session.
If I go with the first approach, with my current specs, I can't process all those at the same time. If I go for the second, and my application for some reason dies, the updates are never stored in the database.
What can I do to solve this problem?
I can only come up with two solutions (both would imply checksums):
Have a secondary application running, which simply creates a named shared memory. The main application will use this memory for the inventory of all the clients, and if it my application dies, then secondary application will keep alive the shared memory, and therefore the data, which can be saved once the main application is re-started.
Map each client inventory directly to a unique file, like the shared memory. However, won't this slow my program? or is it fast as the named shared memory? (If I understand correctly, it should be as fast) (this is the one in my top list right now).
To be more specific about the second approach:
Is there a guaranty, in windows at least, that the following 3 approaches will be as fast in both write/read? If there's ANY KIND of delay,I need to know.
As far as I understand, even the file mapping approach will instantly update the memory, but not the file itself (which is fine).
// normal memory accesss int *normal_address = (int*)0x10203040; *normal_address = 6; //write: 0.00002sec (for example) int get_value = *normal_address; //read: 0.000001sec (for example) // named shared memory int *normal_address = (int*)0x10203040; *normal_address = 6; //write: 0.00002sec (for example) int get_value = *normal_address; //read: 0.000001sec (for example) // memory mapped file int *normal_address = (int*)0x10203040; *normal_address = 6; //write: 0.00002sec (for example) int get_value = *normal_address; //read: 0.000001sec (for example)
Both approaches (memory mapped file and named shared memory) use these functions:
CreateFileMapping OpenFileMapping MapViewOfFile
The main application would be updated in a daily basis, so it can potentially end up with a nullptr or something that. The source code is a bit old and will be updated by multiple persons.
The secondary application would be created once, and never updated unless it's needed. Therefore there's no reason to believe that if the code is well written, no bug should occur in the future to make it crash.
THOUGHTS (ignore if needed):
Perhaps the secondary application could make backups of the data without syncronization: first retrieve the checksum, then get the whole inventory. If the checksum doesn't match, then it tries to do it again.
Perhaps another alternative would be to make the secondary application the one who actually handles the items.
- Everytime a client updates an item, the update would be sent directly to the second application, which would handle the update, and then store the update into the database once the client leaves. Since this application is really small, and it won't change, it's very simple to ensure it won't die. The main application however, will change constantly, which is the reason why it can end up with a null pointer being used by mistake or something like that, and suddendly die.