ORM for stateful application. Is EF compliant? Or any?

Question

I need an ORM that is suitable for a stateful application. I am going to save entities between requests in a real-time low latency game server with persistent client connections. There is only one server instance connected to the database, so no data can be changed from "outside", and the server can rely on its cache.

When a user logs on to a server remotely, his entire profile is loaded into the server’s memory. Several higher-level services have also been created for each user to manage profile data and provide functionality. They can also have internal fields (state) for storing temporary data. When a user wants to change his signature, he asks the appropriate service to do this. The service monitors how often the user changes his signature and allows it only once every ten minutes (for example) - such a short interval is not monitored in db, this is a temporary state. This change should be saved in db executing only 1 query: UPDATE users SET signature = ... WHERE user_id = ... When a user logs out, he is unloaded from the server’s memory after minutes / hours of inactivity. Db is here just for storage. This is what I call stateful.

• Some objects are considered “static data” and are loaded only once at application startup. They can be referenced from other "dynamic" objects. Loading a "dynamic" object should not require a reload of the "static data" reference object.
• Update / Insert / Delete should only set / insert / delete changed properties / entities, even with a "disconnected" entity.
• Write operations do not have to download data from the database each time (execute Select ) to detect changes. (You can track the state in a dynamically generated successor.) I have a state locally, it makes no sense to download anything. I want to continue to track changes even outside the connection area and “download” changes whenever I want.
• When performing operations, references to stored objects should not change.
• DBConnection for the user will not work. Expected online - thousands of users.
• Entities from "static data" can be assigned to the "dynamic" enitity properties (which represent foreign keys), and Update must correctly handle them.

Now I am using NHibernate even though it is intended for stateless applications. It supports reconnecting to the session, but it looks very unusual, requires the use of undocumented behavior and does not solve everything.

I'm not sure about the Entity Framework - can I use it that way? Or can you offer another ORM?

If the server will recreate (or especially reboot) user objects every time the user clicks a button, he will very quickly consume the processor. The CPU scales vertically expensive, but has little effect. Contrary, if you are not in RAM, you can just go and buy more - for example, with horizontal scaling, but it's easier to code. If you think a different approach should be used here, I am ready to discuss it.

Answer 1

Yes, you can use EF for this type of application. Keep in mind that under heavy load you will have some db errors from time to time. And, as a rule, it is faster to recover from errors when the application track changes, not EF. By the way, you can also use NHibernate.

Answer 2

I used sleep mode in a regular desktop application with extremely long sessions: the session starts when the application starts and remains open as long as the application is running. I had no problem with this. I absolutely do not use binding, disconnecting, reconnecting, etc. I know that this is not standard practice, but this does not mean that it is impossible, or that there are some pitfalls. ( Edit: but, of course, read the discussion below for possible traps suggested by others.)

I even implemented my own mechanism for notifying about changes on top of this (a separate thread directly checks the database, bypassing sleep mode), so even external agents can modify the database while hibernate is running, and also have the application take note of these changes.

If you have many, many things that are already working with hibernation, it would be nice to give up what you already have and rewrite it if you are not sure that hibernation will absolutely not do what you want to fulfill.