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

cancel lock? what's needed #24

Open
benoitc opened this issue May 4, 2016 · 4 comments
Open

cancel lock? what's needed #24

benoitc opened this issue May 4, 2016 · 4 comments

Comments

@benoitc
Copy link
Contributor

benoitc commented May 4, 2016

How could we cancel/release a lock before the end of the transaction? Any idea how it could be implemented?

@uwiger
Copy link
Owner

uwiger commented May 4, 2016

From an implementation point of view, it would be pretty straightforward. One would have to think through whether it could cause problems with the algorithm, but I don't think it would.

@benoitc
Copy link
Contributor Author

benoitc commented Aug 20, 2017

where should you i look to implement it?

@uwiger
Copy link
Owner

uwiger commented Aug 20, 2017

Well, locks_server has a function remove_agent(), which among other things calls remove_agent_from_lock(). This could be a starting point for an unlock operation.

In the locks_agent module, there is a remove_locks() function that can serve as inspiration. Also, you should look at the lock request to figure out what checks to run afterwards.

A problem might be the indirect messages. The agents directly involved in a lock will get notified, and the agent performing the unlock will remove its own references to it; it won't get a new message from the locks_server, of course. However, other agents that have received info via locks_agent:send_indirects() should probably receive some counter-info. A possible way to solve that might be for the recipient of an indirect lock info to start a monitor on it. This would be convenient, but most likely expensive. Cheaper perhaps for the agent who has sent indirect messages to remember the {OID, ReceivingAgent} pair for each message, but a complication is that this agent, after removing itself, will not receive the updated lock info.

@benoitc
Copy link
Contributor Author

benoitc commented Aug 22, 2017

ok i will have a look on it thanks for the explanation :)

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

No branches or pull requests

2 participants