Scaling Seaside apps (was: [Seaside] About SToR)

[Chris Muller]

> Well, the idea was to *not* perform modifications in the shared Magma
> session. They would be performed in separate allocated sessions. 

Sounds interesting.  How would you "find" the object(s) to be modified
in the other (mutator) session?  An oid lookup, perhaps?

> Btw, the approach of wrapping each request in an commit block (or as
> we
> do - just an abort before performing the request (we run
> modifications
> to the model in separately started transactions)) has a noticable
> "feel"
> penalty. 

Did you set refreshPersistentObjectsEvenWhenChangedOnlyByMe: true? 
That can kill abort performance, I would try really hard to leave that
off.

Did you know, when you leave that option off, you can:

  - make changes to the model, outside of a transaction
  - send #begin, which will refresh only the objects which were changed
by others, not revert your own changes
  - immediately send #commit, which will commit your changes

This satisfies the "I forgot to begin" use-case, but maybe also a
useful alternative to the performance-killing
refreshPersistentObjectsEvenWhenChangedOnlyByMe mode..

> I did profile the aborts trying to figure out why they take so long
> even
> when there are no changes - but can't recall right now what it was. 

If the profile shows its in MaTransaction>>#restore then the
refreshPersistentObjectsEvenWhenChangedOnlyByMe was turned on, don't do
that.

Otherwise, please post the profile to the Magma list, I'll look at it
promptly.

Regards,
  Chris