You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@bashdi Thank you for sharing this issue. To address the problems with the Query and SqlJob classes, I have started this PR: #68
If multple threads work with the same SQLJob-Object at the same time, which the Pool-Class allows, changing the status leads to -> race condition.
Not sure, if its a good idea to be able to ask the Pool for a SqlJob-Object without ensuring exclusivity through marking or removing it from the pool.
As for this issue, when getJob is called on a Pool, it will get a job as fast as possible. This means it will either be a ready job or the job with the least requests on the queue. Thus, if multiple threads are using the same SqlJob from a Pool, each request should just be queued and thus I expect that the status changing should not have a race condition. Could you share an example snippet to reproduce the issue?
@bashdi The changes in #68 to address this issue with be released in v0.1.0. If you encounter any more issues related to this, please re-open this one or create a new issue.
Looking at the code, I found a few problems with this Lib and threadsafty.
possible race conditions:
Class Query
Creating multiple Query-Objects at the same time -> race condition
Class SqlJob
Calling the method getNewUniqueId which will be called on every interaction with the server -> race conditon
If multple threads work with the same SQLJob-Object at the same time, which the Pool-Class allows, changing the status leads to -> race condition.
Not sure, if its a good idea to be able to ask the Pool for a SqlJob-Object without ensuring exclusivity through marking or removing it from the pool.
The text was updated successfully, but these errors were encountered: