The pattern is identical between the one in the wiki and yours. Simply
move the delete of the key until you're done using the lock, which would
be in a separate request.
In your case, you would probably set the contents of the key to be the
name of the user who has it locked.
In the original pseudocode:
key = "expensive_frontpage_item"
item = memcli:get(key)
if (! defined item) {
# Oh crap, we have to recache it!
# Give us 60 seconds to recache the item.
if (memcli:add(key . "_lock", 60)) {
item = fetch_expensive_thing_from_database
memcli:add(key, item, 86400)
memcli:delete(key . "_lock")
} else {
# Lost the race. We can do any number of things:
# - short sleep, then re-fetch.
# - try the above a few times, then slow-fetch and return the item
# - show the user a page without this expensive content
# - show some less expensive content
# - throw an error
}
}
return item
In yours:
key = filename
item = memcli:get(key)
if (! defined item) {
if (memcli:add(key . "_lock", lock_timeout_time, my_admin_username)) {
[etc]
} else {
# lost the race, handle how you want
}
} else if (item.value == my_admin_username) {
# good to go for that future request
}
Then when you're done holding the lock, delete the key.
On Sat, 4 Jun 2016, Nishant Varma wrote:
> I am reading
> https://github.com/memcached/memcached/wiki/ProgrammingTricks#ghetto-central-locking,
> it seems to deal with a slightly different lock scenario of getting some
> expensive item from Database to avoid "Stampeding"
> In my case its slightly different lock that I need. I show regular files from
> a folder in a web application to many users. So, to "lock" a file using
> memcache isn't this
> simple API sufficient or I still need that pattern :-)?
> def access(filename):
> if memcache.add(filename, timestamp):
> return "Access Granted. Lock Obtained" # Normally this results in
> checking HTML checkbox against the filename so User can do actions with that/
> else:
> return "Access Denied" # Normally this leads to an alert saying that
> someone else is working on this.
>
> Isn't this simple API using add good enough in my case? I am sorry if I am
> repeating this, but I could not really relate the "fetching expensive item
> from Database" to my
> scenario which is why I even wrote a simple script to test the validity of
> the claim etc.
>
> Can you please let me know?
>
>
> On Saturday, June 4, 2016 at 6:42:35 PM UTC+5:30, Nishant Varma wrote:
> Excellent I rely on you. I guess this is the reason you say I am
> over-engineering this problem. Makes sense :-) I will again check the link
> you gave me. I will go
> through the documentation this weekend.
>
> On Saturday, June 4, 2016 at 1:33:04 PM UTC+5:30, Dormando wrote:
> Hey,
>
> You really don't need to test this: I'm telling you flatly, as an
> author
> of this software and all of the documentation for it, that you
> should
> absolutely not rely on that pattern. I'm trying to save you some
> time.
>
> The pattern that is slightly better is written explicitly in
> pseudocode in
> the link I gave you several times in the issue. Please use it.
>
> Thanks,
> -Dormando
>
> On Fri, 3 Jun 2016, Nishant Varma wrote:
>
> > Can anyone help me peer review this script
> https://gist.github.com/varmanishant/0129286d41038cc21471652a6460a5ff that
> demonstrate potential problems
> with get set if it is used
> > to implement distributed locking. I was suggested to modify
> from get set to add in this thread
> https://github.com/memcached/memcached/issues/163.
> However I wanted a small
> > simulation to demonstrate this.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the
> Google Groups "memcached" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send an email to memcached+...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
>
>
> This e-mail message (including any attachments) may contain information that
> is confidential, protected by the attorney-client or other applicable
> privileges, or otherwise
> comprising non-public information. This message is intended to be conveyed
> only to the designated recipient(s). If you have any reason to believe you
> are not an intended
> recipient of this message, please notify the sender by replying to this
> message and then deleting it from your system. Any use, dissemination,
> distribution, or reproduction of
> this message by unintended recipients is not authorized and may be unlawful.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
