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
{{ message }}
This repository has been archived by the owner on Aug 15, 2020. It is now read-only.
Not a priority until we roll out the new minsdb server AND have the test suite in place
We'll need a locking mechanism when accessing the datasource through the DataStore and mindsdb through the upcoming mindsdb interface.
This will need to support locking between processes and ideally it can also be implemented in mindsdb native such that users can use all the APIs in paralle.
At the moment the way mindsdb_server operates with datasources is not, in theory, "concurrency safe" but (especially provided it's run on a linux machine) this should never be an issue in practice.
I don't expect this to b here either BUT at some point we might encounter it and it's better to prepare for these things in advance.
Which seems to be a very well implemented OS-neutral file-system based lock. I've read through the code and tbh I'm not sure the implementation would work out perfectly on all OS-es (i.e. I can see weird edge cases) but it seems to be more than good enough.
The text was updated successfully, but these errors were encountered:
Not a priority until we roll out the new minsdb server AND have the test suite in place
We'll need a locking mechanism when accessing the datasource through the DataStore and mindsdb through the upcoming mindsdb interface.
This will need to support locking between processes and ideally it can also be implemented in mindsdb native such that users can use all the APIs in paralle.
At the moment the way mindsdb_server operates with datasources is not, in theory, "concurrency safe" but (especially provided it's run on a linux machine) this should never be an issue in practice.
I don't expect this to b here either BUT at some point we might encounter it and it's better to prepare for these things in advance.
A good candidate for this is Ilock:
https://github.com/symonsoft/ilock
Which seems to be a very well implemented OS-neutral file-system based lock. I've read through the code and tbh I'm not sure the implementation would work out perfectly on all OS-es (i.e. I can see weird edge cases) but it seems to be more than good enough.
The text was updated successfully, but these errors were encountered: