[Seaside] Re: Seaside and GOODS

[Avi Bryant]

On Thu, 17 Mar 2005 22:46:59 +0800, Yar Hwee Boon <hboon at motionobj.com> wrote:
> 
> On 17-Mar-05, at PM 10:12, Avi Bryant wrote:
> 
> >  I do think,
> > however, that it would be possible to do some aggressive caching in
> > GOODS to improve the situation - I just haven't had time to work on
> > that yet.
> 
> Do you mean modifying the GOODS server code?

No, I mean the client code:

> One thing I thought of trying is, on top of the 1 per session
> connections, keep a long running connection as a read-only cache, be it
> the full database or just a partial version. We can then do lookups
> using this cache and when necessary, pull out a session-specific
> instance for editing using the oid. I *thought* this would be
> especially good for data that has to be sorted against multiple
> columns/fields and presented in a table, and might relieve the need to
> have BTrees, etc. Has anyone tried something like this?

No, and that's maybe better than what I was thinking.  My idea was to
change the GOODS client so that when a given session needs to bring in
an object, it first looks in the local caches of all of the other
sessions to see if they have the same object (in an up to date and
unmodified form).  If so, it grabs a copy of their version.

The thing that's sketchy about this is that the server doesn't know
you've done it, so it won't notify you about any changes to that
object, and it might not deal properly with commit conflicts (have to
think about that one).  So ideally you'd modify the server to accept a
command which was "I've now got the following objects - don't give
them to me, just record that I have them".

So your solution, while less transparent, might be more effective.  If
I understand you right, you'd use the read-only DB almost all the
time, and just explicitly mention when you were going to modify
something:

self session writeableVersionOf: someObject do:
   [:obj |
   ....]

We could also hook this up to a dirty-marking policy so that
WriteBarrier wasn't needed.  A little extra work, but a lot of
benefit.  Neat.

We'd probably also want some kind of expiring cache policy on the
read-only version of the session, so you didn't end up with the whole
DB in your image, but that should be pretty doable.

Re your first point, though: I'm not sure that would stop us from
needing/wanting BTrees.  If you have an index with a million items in
it, you don't want to represent that as a Dictionary holding a single
Array of size > 1000000.

Avi