[Seaside] Re: Seaside & Ruby Rails Compared

[Avi Bryant]

On Sep 8, 2005, at 7:27 PM, Victor Rodriguez wrote:
>
> My concern is that it is very easy to blow away the  object holding
> the data. I guess I need to play around, but I suppouse you initialize
> the class variable in a (class-side) initialize method, then call this
> method using the workspace or some such. Will a class variable set
> like that survive a file-in?

It might not - but keep in mind that the damage isn't permanent until  
you save the image.  If you blew away your data, you'd presumably  
notice right away, and could just revert to the last saved state -  
which hopefully is from right before doing anything dangerous like  
loading new code.  And of course that's not even counting all the  
backup copies of the image you've no doubt been making...

One of the projects I'm working on right now was designed from the  
start to keep the entire data set in the image - we need the  
performance of having everything in RAM, and individual data sets are  
unlikely to get above 100MB or so (there will be many such datasets,  
but those can be partitioned across multiple images, possibly on  
multiple machines).  We've gone through a lot of iterations of how to  
avoid data loss, however, with various vaguely prevayler like  
strategies for logging transactions to external files and databases.   
One of the biggest problems has been evolving the persistence to keep  
pace with a changing data model: not only do you need to extend the  
logging mechanism to support any changes, you've also got to deal  
with all of the historical transactions in the older format on disk.   
In-image migrations are, in general, much easier.     Frankly, just  
using OSProcess to fork and save timestamped copies of the image  
every N minutes is looking pretty good right now.  The question is  
whether you can find an acceptable value of N: high enough that  
you're not using all of your resources on image saves, low enough  
that you're unlikely to ever lose more than a single transaction in  
case of power loss (which is the best you can ever guarantee  
anyway).  Whether or not any such N exists is going to be very  
application-dependent.

Of course, we can only consider this at all because this one project  
happens to have highly partitionable data.  For most of the other  
applications I've worked on, it simply wouldn't be an option to keep  
everything in RAM.  But when it is an option, it's a very appealing one.

Avi