-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
异步保存消息导致异常 #73
Comments
I can only assume that two messages are added simultaneously to the log table which creates a problem with the ID generation. Then the solution might be to use "AddAsync(...)" instead of "Add(...)" which calls the DB instantly for an ID:
@JeremyMahieu |
I see... Sorry for helping introduce this bug. What I think is happening is that two messages with A deeper cause here is that your DbContext is too longlived. You'll get errors because you are doing two operations at the same time and that is not allowed. So ye adding
Idea1: use id -1, -2, -3 etc if needed. ==> might give DbContext simultanious operations error
Idea2: use a temporary DbContext => note I had to borrow the options from the existing context, creating a dbcontext with the constructor like this instead of dependency injection is fishy but doing it properly would lead us much further again.
Idea3: use |
Yes. I know that the lifetime of the DbContexts is longer than usual. I wasn't aware of this at the beginning of the project but it didn't cause any problems. So I kept it this way. The server should probably generate a new one for every message exchange - like a new browser request. But a clean creation of DbContexts is rather unclear (like your solution borrowing the options instance). |
In long lasting services you inject a
|
This bug is very strange. It only exists for the first message after the websocket connection. As long as the first message is successful, this bug will not occur again. This happens after every connection |
In what scenario? Real chargers? How many? Or only simulator? |
@JeremyMahieu |
The current code uses a sync save for the messages again. This should avoid the concurrency. |
WriteMessageLog
_ = DbContext.SaveChangesAsync()
await DbContext.SaveChangesAsync()
The instance of entity type 'MessageLog' cannot be tracked because another instance with the same key value for {'LogId'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see the conflicting key values.
The text was updated successfully, but these errors were encountered: