[Seaside] Re: GOODS

Avi Bryant avi at dabbledb.com
Tue Nov 20 01:33:02 UTC 2007

On 11/19/07, C. David Shaffer <cdshaffer at acm.org> wrote:

> Performance problems with GOODS, in my experience, are typically:
>     1) connection time so I keep a pool of fresh connections around
>     2) writes when the cache is large or when you have large objects to
> compare (arrays, for example) -- this requires some clever flushing
> strategies to fix when it occurs

1) Do you get a new connection from the pool for each seaside request?
 If so, how do you deal with references to objects that stick around
between requests?  If not, how does the pooling work?

2) This idea has come up before but I'm curious what your take on it
is these days: would it help to have a single shared connection that
was used most of the time, and had a very large cache but never any
commits, and then switch to a pooled, small-cache transaction whenever
you need to do writes?  I'm picturing an interface something like

renderItemsOn: html
   connection root allItems do:
       [:ea |
       html anchor callback: [self delete: ea]; text: 'Delete']

delete: anItem
   connection writeConnectionFor: anItem do:
      [:write :item |
      write root allItems remove: item ifAbsent: [].
      write commit]


More information about the seaside mailing list