Memcached StorageService

[Cantor, Scott]

On 9/29/14, 2:31 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>I'm having trouble understanding the usage pattern. Are you making
>successive calls to updateWithVersion with no intervening reads?

Yes, the cache can add data to a session and the version detects
conflicting updates, so it knows to reload a fresh copy and merge in its
changes and then call update again. It doesn't do a read to optimize out
an extra read when the implementation doesn't require it.

>> It's a transactional API, to hide the need to do that exact thing,
>> a read after an update.
>
>I'm fairly certain I can conform to the API contract, but it may not
>be very meaningful and come at the cost of performance.

I'm willing to relax it if it's something we can do with specific methods
or something like that, I'd just rather not lose the feature.

I guess it depends what scenario would be affected by the performance hit,
but like I said, the straight update() call definitely doesn't need to
return it, I can change that.

I can't think of a good name for updateWithVersionReturnBoolean, plus the
method proliferation is a bit nuts already.

>Memcached can't meet that requirement with cas_unique. While it's
>strictly monotonically increasing, it increases by a variable amount
>that is a function of the total number of writes on the cache.
>(cas_unique is backed by a global static variable [1].)

Yes, that's why I left it opaque.

-- Scott