<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Nevin,<div><br></div><div>without giving away any confidential information can you elaborate a little on how you do things? That might be a good scenario for people to know not to care about persistence and scalibility to early.</div><div>I have problems digest what you are saying. Thinking of a single image it can only work if you can have the complete model in memory without problems. Or do you do domain partionioning? It would be interesting to know your approach. </div><div>Second I would like to know how you replay data after a crash. A plain image approach wouldn't help because there is no persitence at all and the data would be lost. Do you replay from another server/system or do you store anything outside the image for error recovery?</div><div><br></div><div>thanks in advance,</div><div><br></div><div>Norbert</div><div><br><div><div>Am 17.04.2011 um 01:37 schrieb Nevin Pratt:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
Define "handful". You'd be surprised.<br>
<br>
We are a large enough company with enough orders, to support more
than a dozen employees, and a half a dozen contractors. Our
warehouse/office is now about 26,000 square feet. And, we're
growing, and profitable, with 2011 looking to be our best year ever.<br>
<br>
The exact numbers are confidential, but I am confident that we are
the largest company on the planet in our field (i.e., "Reborn Doll
Supplies").<br>
<br>
Besides, the orders aren't exactly "hand reentered". I just didn't
give enough detail, because I didn't feel it was relevant. We have
an admin page that can easily slurp the data in rapidly, if needed.
It's not hard to do.<br>
<br>
And Squeak/Seaside has served us well. And we just use the image
for persistence, as previously mentioned. And we are very happy
with it.<br>
<br>
Nevin<br>
<br>
<br>
<blockquote cite="mid:B25FA454-F5E9-4305-9C59-F3D3454A60E2@deepcovelabs.com" type="cite">
<div>Of course that only works when you have a handful of orders
to reenter, which isn't the case for most systems.<br>
<br>
Sent from my iPhone</div>
<div><br>
On 2011-04-16, at 12:41, "Sebastian Sastre" <<a moz-do-not-send="true" href="mailto:sebastian@flowingconcept.com">sebastian@flowingconcept.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>So, 15 minutes times 4 makes a whole hour per year.</div>
<div><br>
</div>
<div>
<div>Beautiful :)</div>
</div>
<div><br>
</div>
<div>Doesn't even justify to implement automation of the
manual rollback (that sounds feasible)</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div>
<div>On Apr 16, 2011, at 1:29 PM, Nevin Pratt wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div 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 moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a moz-do-not-send="true" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
seaside mailing list<br>
<a moz-do-not-send="true" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a moz-do-not-send="true" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>seaside mailing list</span><br>
<span><a moz-do-not-send="true" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a></span><br>
<span><a moz-do-not-send="true" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a></span><br>
</div>
</blockquote>
<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>
</div>
_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br></blockquote></div><br></div></body></html>