[Seaside] Re: GOODS
ssastre at seaswork.com
Tue Nov 20 02:47:51 UTC 2007
> I don't want to interrupt Sebastian as I'm sure he has some
> very good reasons for not liking GOODS. But I do want to add
> that there are several of us using it in production and it is
> a great persistence solution in Squeak. The only problem I
> really have with it (which is not a GOODS problem but a
> Squeak problem) is that commits can be very slow if you have
> loaded a lot of objects in a transaction. That is, when you
> commit the Squeak client needs to check all of the objects
> loaded in your transaction from the database to see if any of
> them are "dirty"
> (have been changed since they were loaded). This process
> involves a linear search which can be very slow when you have
> a lot of objects loaded. I added the method #cacheSize to
> KKDatabase in order for me to be able to monitor this. This
> problem might be solved by WriteBarrier but I've never been
> able to get that to work efficiently. In the mean time I have
> several Squeak/Seaside production applications using GOODS
> and, with some small tuning here and there, they all chug
> along nicely.
Oh Davis please be my guest to add whatever you experienced in this
discussion. I recognise I've tried GOODS (I even made a port of the squeak
client to dolphin smalltalk some time ago) and failed to use it reasonably
for a system of about 40k objects. Even with Btrees and such I was unable to
achieve a half of what I got with any other persistance mechanism. I didn't
work for me.
I see GOODS as a layer of ACID writting of scrutcures in disk not as a more
complete persistence solutions. That gap it's covered by the Avi's Squeak
client of course but with write barrier and all it is still a no go for me.
On the other hand I'm having a good experience with Magma. I moved from
ImageSegments to a magma repository in one day.
More information about the seaside