[Seaside] Re: Seaside & Ruby Rails Compared

Nevin Pratt nevin at bountifulbaby.com
Thu Sep 8 02:25:39 CEST 2005

> I blame the hardware industry. Sure, it doesn't apply to all projects, 
> but consider this - why are you using a database? Doesn't matter if 
> object or relational. Because you don't want to lose your data when 
> the power goes off. So, why don't we have hardware with flash-like 
> main memory? If the power goes off, nothing happens. Power goes on and 
> you continue where you stopped.
> Seriously, if I had a system with few GB of non-volatile ram, I could 
> just keep everything I need in my image for *years* to come and screw 
> all persistence frameworks, because (at least in my case) they solve a 
> stupid problem (electricity) that shouldn't be there in the first place.
> rado

Right-o, rado.

Even with databases (relational, object, or whatever), data must still 
travel through the computer's main memory before it hits the disk, and 
there is still a chance that the power might fail while the data is in 
transit, therefore the databases resort to elaborate transaction 
queueing, two-phase commits, roll forward, roll backward, and all sorts 
of other mumbo-jumbo in order to maintain the integrity of the data 
stored on disk.  So, even databases must deal with the stupid 
electricity problem.  But they deal with it in an effective (but 
complicated) manner.

So, even given the current hardware, if we only had a version of 
Smalltalk that had those same mechanisms-- ie., queueing, committing, 
roll forward, roll backward, etc., that the relational databases have.  
If we had all of those same mechanisms, then the Smalltalk image could 
be restored back to a previous state, or (your choice) rolled forward to 
the last pre-failure state (whatever it was), even in the event of a 
power failure.

Conceptually, the result would be much like the Smalltalk was using disk 
for it's image memory rather than the computer's main memory.  Or, to 
word it another way, conceptually the result would be like doing 
virtually instantaneous and continuous image saves, one after the 
other.  In fact, it would be even better than that, because you could 
always "roll back" to an earlier saved state, whereas with a standard 
image save, you are stuck with the saved version.

So, if they only made a Smalltalk that would do all of that....

... oh, wait, they do!  It's called "GemStone" :-)


More information about the Seaside mailing list