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