On Feb 5, 2010, at 3:28 AM, KaiGai Kohei wrote: > > I have one more point to be issued here. > > Memcached protects an item from concurrent updates using mutex lock > (cache_lock) in store_item. The store_item() acquires a mutex lock > during do_store_item(), so all the updates operations shall be > serialized. > However, it also means we cannot know whether the item to be updated > is already on the cache, or not, outside of the critical section. >
That is an implementation detail in the default storage engine, and you are free to implement this the way you want in your own engine.. > The SET command may work on either creation of a new item or updates > of an existing item, depending on existence of the specified item. > The REPLACE, APPEND and PREPEND command just returns an error if the > specified item does not exist on the cache. > > Even if the security stuff calls item_get() outside of the critical > section to check existence of the specified item, we have no guarantee > any other thread does not create/update the target item. > It is the reason why I put semcd_update_command() hook inside of the > do_store_item(). > Not sure I understand what you are saying here.. do_store_item is called from store_item when we acquired the cache mutex. item_get will try to acquire the same mutex so it has to wait for do_store_item to return and release the mutex.. > But, in the engine mechanism, it shall be handled inside of the pluggable > module. In fact, the do_store_item() is a part of the default engine > routines in the engine subtree. > > Of course, locking mechanism is one of the significant factor which > affects the performance of storage engine. I'm skeptical to enforce > a unique locking mechanism for all the engine modules. > The memcached core implements _no_ locking on items; it is part of the contract between the core and the engine that the items returned by the engine doesn't change when it is returned by the engine. > > It is just an idea. If this efforts should be placed on the engine > project, it seems to me all the security hooks should be included > into server_interface_v1, rather than engine_interface_v1. > If I understand correctly, the server_interface_v1 structure is a set > of function pointers to be called from engine modules. > If we can make clear a set of interfaces that engine module to tell > an access control decision of security provider, we can implement > this feature much simpler. (Of course, the default security provider > should always return 'allowed' to keep backword compatibility.) > That would be possible, but I'm not sure if I see the big benefit of this. I have my doubts that the majority of engines will implement this kind of access control, and if we should create such interface exported from the memcached core it has to be designed in a way so that it works for other systems as well (such as Trusted Solaris). Personally I'm not convinced that this is a feature that a lot of people would use, that's why I believe that it would be great for a specialized engine (and by doing so, it can be tailored to the system you want instead of creating a generalized solution). What kind of access control function did you want the core to provide, and what would be the required change in the core to support this? Cheers, Trond
