[Seaside] OmniBase

[Lukas Renggli]

> > Squeak file IO is ****ed (example http://bugs.impara.de/view.php?
> > id=2149)
>
> This bug has nothing whatsoever to do with omnibase. It's simply that
> source-code access hasn't been touched since the long forgotten days
> of MVC.

Yeah, that particular bug is unrelated to OmniBase, but still there
are some problems in the Squeak filesystem-support related to
OmniBase:

- StandardFileStream>>size does return return wrong results, because
it is (wrongly) cached within the VM, if the same file is opened by
different (native or squeak) processes at the same time. This
particular problem is well known and we already complained several
times, but nobody is willing to remove that EVIL and INVALID caching
from the VM! Well, I could even fix it by myself, but I don't know how
to commit VM changes ...

- Interval>>includes: that is used by OSProcess to simulate
Windows-Filesystem file-locking is extremely slow. A few days ago
there was a discussion in the VisualWorks mailing-list and some years
ago one in comp.lang.smalltalk.dolphin about the bad performance of
this particular method in ST80. Unfortunately this is not easy to fix
and there are a lot of edge cases to take care of, but by writing good
tests it would be easy to find a better solution. John Brant suggested
to use:

Interval>>includes: aNumber
     aNumber isNumber
          ifFalse: [ ^ false ].
     self isEmpty
          ifTrue: [ ^ false ].
     (aNumber between: (start min: stop) and: (start max: stop))
          ifFalse: [ ^ false ].
     ^ step isInteger
          ifTrue: [ (aNumber - start) \\ step = 0 ]
          ifFalse: [ start + (step * ((aNumber - start) / step) rounded) =
aNumber ].

If the community is interested, I could submit the optimization
including a bunch of tests to the mantis-archive for inclusion in 3.9?

- It is not possible to atomically open a file locked, therefor this
requires two operations that could potentially lead to race
conditions.

- We observed in some edge cases that a file was changed by a
different image/process after having it locked. We don't know if this
is OSProcess's, Squeak's or Unix's fault, but putting a short delay
after sort of solved the problem, probably it is caused by some caches
that are asynchronously flushed while or shortly after locking.

- Another rather worrying observation is that OmniBase support for
multiple concurrent images is explicitly unimplemented in VisualWorks,
even-tough the product is sold as being able to support multiple
images. My conclusion is that OmniBase probably never was tested,
never used in production or never really worked for concurrent images
accessing the same db.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch