On 02/21/2011 11:49 AM, Andreas Raab wrote:
> On 2/21/2011 1:31 PM, Miguel Cobá wrote:
>> El lun, 21-02-2011 a las 19:25 +0100, Michael Haupt escribió:
>>> Hi,
>>>
>>> at HPI, we have a SqueakSource with a GemStone backend. The only downtimes we experienced were due to necessary maintenance.
>>
>> I think the number of users that hit squeaksource.com vs HPS's own
>> everyday is a key factor in the perceived performance and net uptime of
>> each installation.
>
> It's not. We used SS at Teleplace at first and it died every other day
> due to heavy commit/update frequency. When we switched to Gemstone we
> never had these problems again. The problem with SS is that it has very
> poor concurrency control. It just trips over its own feet when several
> people commit and update at the same time. I was actually looking at
> fixing these problems at first only to realize that SS was clearly
> designed as a single-user system with very little thoughts being put
> into where and how concurrency plays a role in various operations.
>
> When we switched to Gemsource, these problems went away (though I'm not
> fully sure why). But they did get replaced with others, most notably the
> problem of our entire source code being locked in a system that we would
> be unable to access if our license ever expires. And although we had a
> sweet deal with Gemstone, due to the sweetness of the deal this happened
> every six months and a couple of times in critical release situations.
> After it happened once too many it was deemed to be no longer acceptable
> and we switched to a simple WebDAV based repository. Which has served us
> well.
>
> Cheers,
>     - Andreas
>

Andreas,

The SqueakSource problem is due to basically three things:

   1. issues with concurrent access to the file system
   2. reliance on old (buggy) Squeak vm

With GemStone all of the mcz files are stored as objects in the 
repository and we've had decades of experience persisting objects to our 
repository so the two SqueakSource problems don't exist in GemStone.

At the time that you started using GemStone our license terms were more 
strict ... Since ESUG2010 your requirements would fit within the 
standard license terms ...

Dale