[Seaside] ImageSegments as persistence
ssastre at seaswork.com
Tue Feb 20 12:29:09 UTC 2007
> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre
> de Avi Bryant
> Enviado el: Lunes, 19 de Febrero de 2007 18:59
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: Re: [Seaside] ImageSegments as persistence
> On 2/19/07, Sebastian Sastre <ssastre at seaswork.com> wrote:
> > Avi did you have any progress on that primitive that
> you want for
> > array allocation to disk?
> No. I'm still interested in it if anyone has time.
> > I understood is file based and not atomical (transactional) and
> > that it is like a piece of the image in another file.
> It's certainly atomic in that there is a single primitive
> that builds the segment. But you'll need to do a lot of work
> yourself to get the ACID properties you might want.
Agree. Do you save them in a #critical: ?
> > How much can one rely on them? any experience in production
> > applications?
> Once a segment is successfully built, I've never had any
> trouble loading one into a new image (and Dabble DB has
> produced god knows how many hundreds of thousands of image
> segments by this point). The problems are in building them -
> you have to be *very* careful not to have any outpointers,
> and the allocation of the buffer to build the segment can
> cause low-memory conditions more often than I'd like (hence
> the desire for the disk-based version).
Very nice. Let me see if I understood you right.. by outpointers you mean
that the image segments must be "closed", I mean objects of one segment
should not have references to objets outside that segment right?
I think I saw the OS automatically giving more memory to a squeak in low
memory condition in windows but not in linux. How do you manage a low memory
> > I think, that if reliable, it is an interesting option
> for seaside
> > applications that do not require transactions.
> If you understand and can carefully manage them, they certainly are.
> But they're hardly an "out of the box" persistence solution.
Right. When one use this to persist, in your opinion, how one should decide
to make a "save" on them? By an event? By time? How ofen?
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside