Shibboleth Developers

["Scott Cantor" <>]

> > I would say you've got two options:
> >
> > - implement a plugin that doesn't support write integrity and always
assumes
> > the data is in sync, which is probably good enough for most deployers
>
> Can you tell me, in a worst case scenario, what can happen?

Nothing in 2.0 proper is going to be writing back to the cache, so nothing
will happen unless you can't update the expiration time itself, which it has
to update separately on every request, to handle timeouts.

I don't version that particular kind of update because the race doesn't
matter, the last one in is fine.

If components start adding attributes or tokens to the cache later, then the
risk is losing them if two nodes do it at once.

> But this has two problems:
> - if the copy stored on the server is already a version ahead the add
> will work since the key will not conflict
> - if the version is part of the key, and you don't know which version
> is stored, you can't retrieve the value

Yes, sorry, you're right. He's trying to support read-only caching, which is
fine, but the session cache isn't formally read-only, at least in theory.
 
> You could store the version number separately and increment it with
> the memcache methods but i think eliminating race conditions without
> locks is next to impossible.

Yes, I think you're quite right.

>  From the Shib DEV pages in the Wiki there are a lot of features
> still in development or not started, including the single-logout
> feature which is what I miss from 2.0, so I guess 1.3 will have to
> do. It has proved stable.

The 1.3 caching API is much worse, but that aside, it doesn't really work
well, and it has race conditions inherent in the design. Clustering it was
never really a goal, I don't know of anybody but one place trying to do that
while still using that session cache.

-- Scott