Replace synchronized with ReentrantLock #95
Conversation
Replace connectionMutex and synchronized blocks with a ReentrantLock. The synchronized blocks were removed and replaced by `lock.lock()` and `lock.unlock()`. This avoids that the carrier thread (OS thread) is pinned when running on virtual threads which were introduced as a preview feature in JDK 19. The JEP that is being prepared for JDK 21: https://openjdk.org/jeps/8303683 `There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: When it executes code inside a synchronized block or method, or When it executes a native method or a foreign function.`
|
Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment: |
|
I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it. |
|
Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow |
|
Is there any plan to get this merged ? |
|
Hi @masoudparvari, we do have plans to analyze it thoroughly and may consider merging it. That work hasn't been completed yet. It's a significant change and we need to be very careful to avoid causing damage to others. I hope you understand. Thanks, |
how long ? i want to use virtual threads with mysql .. |
|
Why this was closed :(
|
|
It's how Oracle MySQL's contribution process works. Follow up in the bug report mentioned in the last post by @mysql-oca-bot. |
Replace synchronized blocks with a ReentrantLock. This avoids that the carrier thread (OS thread) is pinned when running on virtual threads which were introduced as a preview feature in JDK 19.
The JEP that is being prepared for JDK 21 still contains the limitation:
https://openjdk.org/jeps/8303683
`There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:
When it executes code inside a synchronized block or method, or
When it executes a native method or a foreign function.`
This PR makes the following PRs obsolete as it replaces them:
#91
#93