<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sebastion, that is *exactly* what I initially did at Bountiful
Baby. However, it has been several *years* since I've had to do
your #4, so things have changed slightly since. <br>
<br>
Bountiful Baby is an eCommerce site, and the critical "object graph"
(your #2, below) information consists of inventory data (the website
keeps track of our inventory), and gift certificate data (for gift
certificates that have been issued). Also, whenever either of those
datums change, the website sends an email-- for example, emails are
(obviously) sent for each order accepted, and, it sends emails when
it issues a gift certificate. So, it is easy to discover (via the
emails) what data was lost since the last image crash.<br>
<br>
Consequently, currently this is what happens:<br>
<br>
1. image is saved from time to time (usually daily), and copied to a
separate "backup" machine.<br>
2. if anything bad happens, the last image is grabbed, and the
orders and/or gift certificates that were issued since the last
image save are simply re-entered.<br>
<br>
And, #2 has been *very* rarely done-- maybe a two or three times a
year, and then it turns out it is usually because I did something
stupid.<br>
<br>
For us, it's a whole lot easier to do persistence this way than
bothering with any persistence mechanism. And, it turns out, it is
*very* reliable, with exactly one easily fixable glitch:<br>
<br>
The glitch is: occasionally the production image UI will freeze, for
no known reason. It doesn't effect Seaside, though, so the website
keeps going just fine. And, if we run the "screenshot" app (in the
configuration screen), there is a link at the top for "Suspend UI
Process", and "Resume UI Process". Just suspend and resume, and the
UI becomes unstuck.<br>
<br>
We've been doing persistence this way for years now, and I've been
*extremely* impressed with the reliability.<br>
<br>
Before that, we used PostgreSQL and GLORP for persistence. But I
yanked that code out years ago. It wasn't worth the bother
maintaining it. <br>
<br>
If you have a daily image save, then on average there will be 12
hours of lost data on a "random" crash. Re-entering 12 hours of
orders and/or gift certificates (discovered from the emails, as
mentioned above) might take 10 to 15 minutes. Not a big deal at all
for us.<br>
<br>
Ten years ago I wouldn't have even considered doing persistence this
way, but I've changed. Squeak has changed. Seaside has changed.
And all for the better.<br>
<br>
Nevin<br>
<br>
<br>
<br>
<blockquote
cite="mid:DCBD59A6-5593-4214-A21D-33E9AA6D47C9@flowingconcept.com"
type="cite">
<div>Given that you don't need transactions, to make that style
work, I suggest this:</div>
<div><br>
</div>
<div>1. save the image from time to time (as best suits your
needs) like you're doing now</div>
<div>2. use a secondary way to dump the object graph</div>
<div>3. use the normal image for as long as things are good</div>
<div>4. when shit happens you "transplant" the object graph into a
new "reincarnation" of your app in a fresh image</div>
<div>5. repeat</div>
<div><br>
</div>
<div>For dumping the ODB you have options: image segments, SIXX
comes to mind now</div>
<div><br>
</div>
<div>If you make for yourself some "rescue" kit (script, tools,
preloaded code in fresh image), you can make 4 quite painless
(or, why not, monitored and automated)</div>
<div><br>
</div>
<div>
<div><a moz-do-not-send="true"
href="http://twitter.com/#%21/sebastianconcpt">sebastian</a></div>
<div><br>
</div>
<div>o/</div>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<div>On Apr 16, 2011, at 12:23 PM, Michal wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div><br>
hi - <br>
<br>
Despite the warnings, I am really interested in sticking to
the<br>
simplest way of saving my seaside application data, ie
periodically<br>
saving and backuping the image. The seaside book states that
<br>
<br>
"saving [the image] while processing http requests is a
risk you<br>
want to avoid."<br>
<br>
What is the status on that? Is that something we can fix? I
have been<br>
running an image in this mode for a few weeks, with no ill
effect so<br>
far, but I have had major problems with old image/vm
combinations. So<br>
is this something that might be fixed already?<br>
<br>
Also, I recall that Avi had made a number of attempts at
having an<br>
image saved in a forked background process, eg<br>
<br>
<a moz-do-not-send="true"
href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/095547.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/095547.html</a><br>
<br>
did anybody pick up on this, or did anything come out of it?<br>
<br>
thanks, <br>
Michal<br>
_______________________________________________<br>
seaside mailing list<br>
<a moz-do-not-send="true"
href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
seaside mailing list
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
</pre>
</blockquote>
<br>
</body>
</html>