Skip to content
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

DefaultSimpUserRegistry Use ReentrantLock to Prevent Pinning #34538

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

csh0034
Copy link

@csh0034 csh0034 commented Mar 5, 2025

modified the part where pinning occurs in DefaultSimpUserRegistry due to the use of synchronized when using VT
I would appreciate any feedback 😃

Signed-off-by: SeungHun Choi <csh0034@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 5, 2025
Copy link

@pankratz76 pankratz76 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nicely done

Comment on lines +116 to +117

this.sessionLock.lock();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
this.sessionLock.lock();
sessionLock.lock();

There is no overloaded field that makes the this. access required, right? Both are correct, but if there is no ambiguity, it's more concise to leave it out.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your valuable feedback.
I actually considered this when making the code changes.

Looking at other classes that use ReentrantLock, I noticed that they all include this.
so I decided to keep it for consistency.
(e.g., SubProtocolWebSocketHandler, InMemoryWebSessionStore.ExpiredSessionChecker)

@jhoeller
Copy link
Contributor

Are you experiencing any actual pinning there? The code within those synchronized blocks is not performing any blocking operations as far as I can see. From that perspective, it should be fine as-is.

@jhoeller jhoeller added status: waiting-for-feedback We need additional information before we can continue in: web Issues in web modules (web, webmvc, webflux, websocket) labels Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants