-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Session JDBC mysql innodb deadlocks #1027
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
Comments
Thanks for the report @isalnikov. Are you getting these deadlocks running on single instance of your app, or in cluster (perhaps with MySQL in multi-master setup)? We've had a couple of similar reports - see #676, #838. Multi-master setup is troublesome in highly concurrent environments, and there's little we can do about that. If you're running in a cluster I'd recommend setting different cron expression for each of your nodes, so the session cleaning jobs don't overlap. Regarding the auto incremented primary key, I'm afraid that's not a viable solution for us as we need to support multiple RDBMS vendors and that means vendor specific features like that aren't suitable. |
Closing due to lack of feedback. Please re-open the issue if you can provided more details. |
Hi, maybe we need understand and fix this issue. Why it has closed status? |
More details from logs.
|
@TorosyanV , да тут бесполезно что то объяснять , они делают универсальную вещь . Проблема дедлока в том что : в мускуле нельзя делать PK как строка да еще и UUID - идея PK что это индекс и он монотонно должен расти. Дедлок:
Удаление делать так :
Делать ролбеки чтобы после дедлока можно было откатиться .
|
Thanks for following up @isalnikov, although please try to keep your comments in English. I'm reopening this to double check if there's anything we can do on our side, and I'd appreciate if you could come up with a sample that reproduces this issue. Also provide as much details as possible about your environment. |
Closing as it doesn't appear that we can do anything here in an RDBMS vendor neutral way. The thing that might help would be introduction of session id generation strategy that was proposed in #11 so please track that issue and feel free to vote on it. |
Marking this as a duplicate of #838. Please subscribe to that issue to track further updates. |
private static final String CREATE_SESSION_QUERY =
"INSERT INTO %TABLE_NAME%(PRIMARY_ID, SESSION_ID, CREATION_TIME, LAST_ACCESS_TIME, MAX_INACTIVE_INTERVAL, EXPIRY_TIME, PRINCIPAL_NAME) " +
"VALUES (?, ?, ?, ?, ?, ?, ?)";
private static final String DELETE_SESSIONS_BY_EXPIRY_TIME_QUERY =
"DELETE FROM %TABLE_NAME% " +
"WHERE EXPIRY_TIME < ?";
I found the cause of the deadlock when working with mysql.
When one thread inserts a new record into the table it gets a s lock
the second thread does the deletie of the old sessions and gets the exclusive X lock
so in the mysql engine it is necessary for the key to be monotonously increasing.
CREATE TABLE SPRING_SESSION (
https://stackoverflow.com/questions/46106485/mysql-using-a-unique-char-as-primary-key
It is valid to use a UUID as a primary key. It meets the two conditions required of a primary key:
It is unique.
It is never NULL.
However, it is a bad idea. Why? MySQL automatically clusters the data by the primary key. That is, the data is actually sorted by the primary key. UUIDs are not sequential. Inserts can occur anywhere, requiring movement of data.
I would recommend a simple auto incremented primary key and declare the UUID as unique
The text was updated successfully, but these errors were encountered: