[aida] 6.2 news: Image based persistency

Chris Muller asqueaker at gmail.com
Thu Feb 24 20:13:36 CET 2011


> I namely run my hosting business for 7 years now on image based
> persistence, on VW image currently around 600MB in size. Without any
> loss of data in whole 7 years!

Of these two prongs of risk-management; 1) the chance of something
going wrong, and 2) the penalty if it does go wrong; I already
expressed my agreement in my original post that a loss is unlikely.  I
was criticizing the other prong, which is the high penalty IF
something went wrong with the image.  I see no way to recover it other
than trying to dig the domain objects out of the binary image file.

The possibility of havoc could be wrought not only by image / VM
instability.  It could be the Aida end-users application logic.  Maybe
they deploy some new feature and it has a bug that slightly corrupts
the domain model over time.  This is a situation where a database with
transaction logs can help, since you can recover the model to any
point in time.

I am not against image-based persistency, I just was saying that I
like to be conservative about _advocating_ it, particularly in this
manner that ignores the 2nd RM prong..

> With Eliot as VW VM designer now working on Squeak/Pharo VMs I'm sure we
> will soon achieve similar stability and therefore suitability for
> Squeak/Pharo image based persistency as well.

I'm not sure what VM stability problems you refer to.  We've had
non-Cog VM's running in production for years; zero downtime due to the

>> What happens if the model grows faster than expected beyond memory
>> capacity?  How do you get your app ported over to GemStone w/
>> licensing, etc. and back up and running quickly?  How does one
>> "upgrade their image" if the model is stuck in an old image?  Does the
>> image save start to take longer and longer as the image grows?
> Those if not all reasons goes int that 1% of special cases I wrote. At
> least on VW I upgrade an image by "filling-out" all objects and file in
> on the fresh one. This is called BOSS-out/in on VW, while on
> Squeak/Pharo I still need to check the right way doing it.

I know of BOSS, I'm curious why to advocate image-persistency"
strategy over using that?

Incidentally, the Squeak equivalent is SmartRefStream or MaObjectSerializer.

> I came from VW world and start with Gemstone back in 1998, while coming
> to Squeak and heard about Magma about 4 years ago. This is one of
> reasons why I don't know it much, the other is that Gemstone actually
> provides near 100% transparency (you don't need to know any Gemstone
> specifics)
> while on Magma you need to program the Magma presistency,
> AFAIK. Which means that you became dependent on Magma, therefore your
> code is not portable anymore. While on Gemstone because of so strongy

Hmm, I'd like to know the basis of these assertions.  As far as I can
tell from my working with GemStone (since 1999), Magma has essentially
the same level of transparency.  You operate in a session, and at some
point you have to tell it to begin and commit transactions.  That's
essentially the only intrusion into "100% transparency," but this is a
_good_ intrusion, since you need to be able to define proper atomic
boundaries for altering the domain consistently.  In GemStone,
thankfully, you have the same requirement:  You have to open a Gem and
tell it to commit at some point in the code.

Friedrich was also wrong when he referred to Magma as a relational
mapper.  Rest assured, it is an ODBMS 100% with transparency
comparable to GemStone.

> transparency it is. Magma is also working only on Squeak (Pharo?), while
> Aida apps are working and directly transferable to 6 dialects now.

By "directly transferable" do you mean with zero code changes?  If so,
that's really impressive!


More information about the Aida mailing list