Magma March 2006

magma@lists.squeakfoundation.org

9 participants
21 discussions

[Q] changing keySize:
by Norberto Manzanos 25 Apr '06

25 Apr '06

Sorry for bother you with these elementary questions. I am playing with differentes keySizes in indexes, but everytime I change the keySize of an index and rebuild the database Squeak hungs (or it takes too much time to do the task). I'm saveving only 200 objects in a one single entry with two indexes. The first time I save them, its very fast, but when I begin playing with differents keySizes, Squeak loops. Normally I close the session (a single user sesssion) and reopen it, before to rebuild the database and the indexes, but I have tried even deleting the db files and recreate them. I thought its must be something about references that remains in my image, so I try to find how to perform a garbageCollect of Magma. I found a comment in MagmaCompressor that says "yourRepositoryController garbageColllect". But this object does not understand #garbageCollect, nor any other magma object. Would you give me any hint? Or something to read about that? Thank you in advance. Norberto

3 8

Magma on 3.7 report
by Bert Freudenberg 29 Mar '06

29 Mar '06

Hi folks, Göran assured me that Magma was the Best Thing Since Sliced Bread so I decided to try making my 3.7-based seaside app use Magma for persistency. According to the Wiki, 3.7 and 3.8 are supported (http:// minnow.cc.gatech.edu/squeak/2665). However, when installing via MagmaServerLoader-cmm.13 in 3.7, these definitions failed: ByteString>>maAlphabeticalNext StrikeFontSet class>>maMaterializeFromGraph:using: StrikeFontSet>>maAsStorageObject StrikeFontSet>>maUsesStandardStorage Apparently there are no senders of maAlphabeticalNext, and I do not use fonts, so I think I can ignore these. After loading there is an undeclared MagmaCollectionContext in MagmaCollectionReader>>maNewSearchContext but this is unsent, too, so safe to ignore. Apart from that, things looked nice :) - Bert -

4 17

using WriteBarrier
by Chris Muller 29 Mar '06

29 Mar '06

> Would using WriteBarrier be as simple as "myMagmaSession > allowWriteBarrier: true"? What drawbacks are there? Once you load WriteBarrier (which I'm not sure how to do these days), yes, that should be it. I would not recommend turning it off and on while sessions are connected. I was really excited about WriteBarrier at one time because it improves the peak commit rate from 24 per second to >100 per second. It's another a great idea from Avi. I put some real work into supporting it with Magma but there is one test case which can't pass with WriteBarrier. #testClassSchemaUpgrades simulates developers changing the shape of classes with existing instances in Magma, that other users can run their version of the in-image class "out-of-sync" with the repository and not accidently truncate data. If you comment out that test case, all the others should (and did, last year at least) pass. It turns out the problem lies within WriteBarrier's interaction with Squeak's metaclass layer. It is exposed by changing the instance variables of a *superclass*, such as: Object ClassA ClassB and changing the instance variables in ClassA will not work with WriteBarrier turned on (with or without Magma). I spent several late nights trying to fix it but I couldn't fix it. I still have detailed notes and scripts to reproduce the problem if you or anyone else wants to give it a shot. Besides that bug and the fact that I haven't tested it in months, also know that I don't really have the time (or skill, apparently) to support it. If you have problems running with WriteBarrier, I probably wouldn't be able to help. - Chris

1 0

MagmaTesterLoader-cmm.20
by Chris Muller 29 Mar '06

29 Mar '06

I have just posted the improvements based on "Magma on 3.7 report" from Bert. This 1.0 release now minimizes the impact of cleaning up the 'objects' Dictionary that was causing some performance issues. It also restores use of MaWeakValueDictionary which is many times faster with large dictionary's than a plan WeakValueDictionary. MagmaServerLoader and MagmaClientLoader were also udpated, of course. There's also a bug fix related to specifying depths for variables defined in superclasses. Enjoy. - Chris

1 0

repository recover procedure
by Marcelo Cortez 28 Mar '06

28 Mar '06

hi all i 'have one magma database and at startup fail. the message is 'Invalid index size. Requires maintenance tool.' what tool?? any clue ? best regards MDC

2 1

[Newbie] [Q] How yo install magma?
by Norberto Manzanos 27 Mar '06

27 Mar '06

Hi. I'm traying to install Magma, but the instructions are not clear. I added http://squeaksource.com/MagmaTester as a Monticello repository, but then, how do I know what is the "main" package? Is it Magma1.0.mcz? Or MagmaTesterLoader? Any package I tried to load raises an error. Is there any depedency not explicity registered in this main package? Thanks in advance Norberto Manzanos

2 1

New Magma 1.0 (was: Magma on 3.7 report)
by Chris Muller 24 Mar '06

24 Mar '06

Ohhh K !! Bert, I think you saved the day. Your shocking MessageTally has revealed that Magma has sufferred a horrible performance regression; it is back to using WeakValueDictionary instead of my own faster "MaWeakValueDictionary". Monticello shows I took it out last September 21st, 2005. The comment indicates I did this intentionally: "- No longer using MaWeakIdentityKeyDictionary and MaWeakValueDictionary. These perform immensely better with removeKey:, but am now avoiding removeKey altogether." I stupidly failed to realize #removeKey: wasn't the only issue with WeakValueDictionarys, its #at:put: is a serious problem as well. This is why you are experiencing this major performance problem. I'm rather wringing my hands suddenly realizing, all this time, everyone who has a few hundred-thousand locally cached objects has (probably) been experiencing horrible performance. :( I'm surprised Bert is the first to notice and mention since that time. So I have restored the use of MaWeakValueDictionary, verified with the test cases, and reposted to SqueakSource. **Everyone should update to this latest version**. It appears WeakIdentityKeyDictionary has been fixed, so it was right to stop using MaWeakIdentityKeyDictionary. Bert, thanks for your patience and great help in exposing the problem. Would you please try your test again? MagmaServerLoader-cmm.14.mcz on SqueakSource, it should be about 4-times faster. - Chris

1 0

Re: Save vs. Commit
by Chris Muller 23 Mar '06

23 Mar '06

----- Forwarded Message ---- From: Chris Muller <afunkyobject(a)yahoo.com> To: magma(a)discuss.squeakfoundation.org Sent: Wednesday, March 22, 2006 3:01:03 PM Subject: Re: Save vs. Commit Hi again, > there is a fitting commit strategy dubbed "2) User-controlled > transactions, with auto-begin". So if I understand correctly, I would > open a session on startup, get the root to load my model, do a > #begin, and in the "save" method I just do a #commitAndBegin. Right? Yep, this should work. > I intend to do all of this as single user using a local session in a > single server image - is there anything I'd need to watch out for? > Like, is there a time-out on the session? There is no time-out based on time. There is a way a session can be "kicked off" in a multi-user setting. It's when other users are very active with commits and you are not at least refreshing (begin, commit or abort) for a long time. Their object changes get piled on to your session (in the server), growing the servers memory consumption. If you wait too long, your session will get too many pending updates and the server will be forced to disconnect your session. GemStone does the same thing, but I hope to find a way around this some day.. But this can never happen in a single-user setting. Cheers, Chris

1 0

Re: 10 MB limit?
by Chris Muller 23 Mar '06

23 Mar '06

This was my lame attempt, a looooong time ago, to "protect" the server from too-large a commit because it would take long time and a lot of memory and potentially "disrupt other users". It also is there for "the spirit" of small and short transactions. 10MB is not going to be a short transaction. But your question is about loading of legacy models, which is not handled very well. Most large models are accessed dynamically from disk, so committing them piecemeal is natural, but in your case you had a "medium" sized model that loads entirely into memory, just more than 10MB.. So I must admit I'm at a loss for the best way to handle it other than get rid of that check, and expect the commit to take quite a long time. Ma object serialization is the framework which serializes objects into first-class "Buffers". These buffers are logical representations of Squeak objects, with 48-bit oids as well as other information. Though they are less-compact than Squeaks native (physical) format, they permit essential server-side processing such as navigation, compression, browsing the model (without domain classes loaded) and more. They are also crucial to future planned replication functions. If I were to point to the "core" of Magma, I would have to say it is these first-class buffers (MaObjectBuffer et al).. - Chris ----- Original Message ---- From: Bert Freudenberg <bert(a)impara.de> To: magma(a)lists.squeakfoundation.org Sent: Wednesday, March 22, 2006 7:56:11 AM Subject: 10 MB limit? I just tried to import an existing domain model into Magma, by giving it as root when creating the repository. The models serialized size was 6 MB before (using DataStream). However, the commit failed with a notice that a commit must not be larger than 10 MB. Now I worked around that problem by splitting the model and re-adding parts in separate commits later, but wouldn't it be nice for a one- time import to lift the limit? Why is it there? - Bert - _______________________________________________ Magma mailing list Magma(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma

1 0

Save vs. Commit
by Bert Freudenberg 22 Mar '06

22 Mar '06

I am converting a legacy app that uses explicit "save" operations after each change to the domain model. Changes are rather infrequent (like 10-50 per day). It used to be the case that a "save" just serialized the whole model. Now to adapt this to Magma I'd rather not wrap every modification into a commit block, but use the existing "save" call to commit. According to http://minnow.cc.gatech.edu/squeak/5605 there is a fitting commit strategy dubbed "2) User-controlled transactions, with auto-begin". So if I understand correctly, I would open a session on startup, get the root to load my model, do a #begin, and in the "save" method I just do a #commitAndBegin. Right? I intend to do all of this as single user using a local session in a single server image - is there anything I'd need to watch out for? Like, is there a time-out on the session? Thanks! - Bert -

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma March 2006