Shibboleth Developers

[André Cruz <>]

On May 3, 2007, at 5:10 PM, Scott Cantor wrote:

> I think the race conditions would be a problem. Without any  
> locking, you
> can't be certain that you're not overwriting new data. The normal  
> approach
> would be to lock, select version, compare, then update. With no  
> lock, you
> can't protect the select/compare step.
>
> 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?

> - implement versioning by embedding the version inside the key value
>
> You could do things like "add" the new version and then if you  
> conflicted,
> you'd detect it, fetch the updated version, bump the version and  
> try again,
> etc.

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

Even if the add gave an error, you would have to return the new value  
to the calling application so that it could process it again and  
generate the correct value to store.

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.

> (This is all 2.0 I'm referring to, I wouldn't even consider  
> touching 1.3,
> the API is horrible.)

I would target 2.0, if I knew when it would come out... This project  
is going into production soon so I can't count on something that is  
not out yet (and probably will need some testing when it is).

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.

Regards,
André