[Seaside] Re: GOODS

[C. David Shaffer]

Avi Bryant wrote:
>
> 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?
>   
No, this pool is just a small set of "fresh" connections that I keep.  
When a new seaside session is created it gets a session from this pool 
and, I kick a background process that creates another connection to fill 
the empty slot in the pool.  It is important that these connections have 
_no_ objects loaded on them otherwise they will cause GOODS to queue 
object change notifications.

> 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
> this:
>
> 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]
>
>   
Yes, I did something very similar.  Since I had hidden all mutation 
inside command objects each command went through a transition from one 
transaction to another before it executed.  Each command was responsible 
for supplying the list of GOODS objects that needed to be moved.  Worked 
very well.  Oddly enough I didn't use a single read-only 
transaction...each session still had its own read transaction.  Maybe 
the next step would have been to get rid of that obvious redundancy but 
that would have required making the transactions thread-safe.  As I 
recall something had to be done to make sure that the read-only session 
saw changes at reasonable points (I think my commands sent #refresh to 
the read-only session after the command was complete).

David