Hi guys, I came to this post today due to having what can be described as an unexpected voyage behavior and was greatly impressed by all the detailed descriptions and explanations. Thanks everybody for that!
Also thanks Peter for mentioning that port I did back in the day (~2009) for using OmniBase [1] in Aiflowing [2] where it achieved sub-second page renderings with a full ACID, multi-image scalable setup. Is not actively maintained but I think is a piece of software that is worth not having it lost. The concept alone, filesystem based B-Tree object persistance, is neat and can be the foundation of a lot of stuff. Now I wonder what Esteban's fork has that couldn't be a merge request, I would gladly take a look if open. I feel bad about you loosing time with testBTreeKeyLocking because you won't find the issue inside smalltalk. As it depends on the OS' file system to detect concurrent changes in an object, you need the kernel of that system to be supporting mandatory lockings [3] which is a feature that linux and macOS does not have turned on by default. As mentioned in the readme of the project you need to activate it in order to OmniBase raise an exception preventing you of a race condition writing an object (coming it from a transaction from another image or from another thread in that very image) that would create db corruption or inconsistency. Note that, with mandatory locking active in your OS kernel, the transaction that comes later will raise an exception hence that test will pass. By the way, Windows has mandatory locking by default. *Back to the issue about voyage* here, I see the whole issue happening simply because Voyage is caching by default hence forcing all Voyage users to deal with one of the nastiest problems in computing: cache invalidation. Yesterday I faced this issue: 1. changed a mongo document from a mongo client and 2. querying it from Voyage revealed different state (the state before 1). This makes no sense at all. It makes Voyage not to be useful for interoperation with other applications and languages, it makes it impossible to scale an application in more than one Pharo image (all the main well proven cloud platforms requires stateless built artifacts to horizontally scale apps), on top of the lack of horizontal scaling issue there is the issue of high availability that now you can't do because you are forced to have a single point of failure (one vm behind the load balancer instead of N). But all those issues go away if Voyage simply does what a persistent client is normally expected to do: save and query documents in the mongo repository. By trying to do too much, like deciding that caching all inside the session open in a given image is a valid design, it actually becomes less powerful and surprises users in the worst way. Might be valid for a prototype but certainly not for high-availability and high-load demanding applications in production. Caching is a great thing but is an application design decision, not a persistency client decision. That concern is not for the client but for the engineers who use it to make an application that might have /some/ of its persisted models cached but certainly not all, except on very limited scenarios. If you think about it, this is how things become niche. Now in an application where I'm using Voyage expecting that queries return what is actually in mongo I have to architect things in a way that workaround this issue, like purging that cache somehow with some kind of policy (time or a given event). I like Voyage and I'm grateful for all the effort Esteban and the contributors are putting into it. I might add a merge request myself. Is documented, works well, has really nice features and is intuitive. It's just this /cache all by default/ part that I don't think belongs to it and if removed it would be a more powerful mongo client. [1] https://github.com/sebastianconcept/OmniBase [2] https://pharo.org/success/AirFlowing [3] In *nix systems it requires mandatory file locking, so be sure you use mand on your fstab. https://www.hackinglinuxexposed.com/articles/20030623.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
