Hi Lukas -

Let's leave the storage alone for a second, what I'm really curious 
about is how Squeaksource protects against concurrent modifications. I 
don't know all that much about Seaside but as far as I know Seaside 
doesn't have any builtin mechanism to deal with serialization of 
concurrent requests and there doesn't seem to be any request 
serialization in SSRepository that I can see. So how exactly does this work?

My big suspicion is that the SSFileRepository>>saveRepository: interacts 
with concurrent modifications of that very same repository. That 
suspicion is mostly due to:
* me not understanding how Seaside / Squeaksource protect against 
concurrent modifications internally
* the singular use of a single critical section for saves only (!)
* the priority of the save being lower than normal which ensures that 
(unless there are other means of synchronization that I am not aware of) 
any request that comes in during the save *will* concurrently modify the 
repository being written.

I don't think any of this has to do with Semaphore or Delay issues 
(although these issues certainly don't help the situation); it's just 
plain concurrency issues.

Cheers,
   - Andreas


Lukas Renggli wrote:
> www.squeaksource.com has almost 1000 projects with more than 25000 versions.
> 
> It works without problems for years now. The only issue we recently
> had could be fixed by loading the Semaphore patches of Andreas.
> 
> The image storage works very reliable, we never had a problem with that.
> 
> Lukas
>