[Seaside] ImageSegments as persistence

[Sebastian Sastre]

> -----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
condition?

> 
> >     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?

Thanks,

Sebastian 

> 
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside