Evaluating Magma

[Chris Muller]

Thanks for your cents Sebastian.

I must agree with:

> newcomers will allways found the default behavior of
> #refreshPersistentObjectsEvenWhenChangedOnlyByMe in false
> as a strange thing.

because this question is asked a lot.  Like you, everyone seems to be
surprised by this.

But, notwithstanding the above the nature of some applications will
insist the users work not be disturbed upon crossing a transaction
boundary or commit failure.  The default to this preference is false
because it is more conservative with the users work and also performs
better.

> Heuristically is preferable that the default where true

Why?

> Questions (I didn't saw in FAQ):
>
>     . I know I'll probably do not implement (nor want to) it but I need to
> know if it's planned to support pessimistic locking somtime.

I have no plans to do it.  But could this be handled at the
application-level anyway?

>     . there is an idea of how many concurrent clients (sessions) can be
> served by a squeak image? or any other metrics relevant to measure load
> capacity/scalability? OK I've re-read Magma limitations, there is any news
> on this?

Since there are so many variables in this question, check out the
Magma performance benchmarks page which may help you answer for your
intended use..

  http://wiki.squeak.org/squeak/5606

>     . there is an idea of how much is Magma resistant to power faliures?
> (sata drives with software raid)

It is very robust in this area.  Partial writes are detected and
recovered automatically.

 - Chris