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

Correct locking. #3

Open
addiks opened this issue Nov 29, 2015 · 0 comments
Open

Correct locking. #3

addiks opened this issue Nov 29, 2015 · 0 comments

Comments

@addiks
Copy link
Owner

addiks commented Nov 29, 2015

Currently there is no locking at all. For in-memory databases (without threads) this is not a problem, but it will become a problem when the database is saved on the actual filesystem.

There must be a way to lock tables or rows.

Implementation plan: While the table- and column-data- implementations work with the actual files, the executors use abstract data-providers (filters, orderers, ...) that themself use arbitrarely deep nested the actual implementations. That means we need an Interface (LockableInterface) that indicates that this data-provider can be locked. The column-data/table/schema implementations will do actual locking and the other data-providers will just forward the lock-operations. Maybe have the actual locking done by a seperate class of components (Lockers?) that can depending on the implementation either just use the 'flock' functions or use more complex semaphores.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant