Magma

magma@lists.squeakfoundation.org

722 discussions

Shutdown
by Facundo Vozzi 08 Feb '11

08 Feb '11

Hi all, I'm testing my app on a production scenary where I would have a UPS conected to the server running magma. If I have a electrical power failure then the UPS send a signal to the server for shutdown it and in that moment I would like close all magma conections securely and shutdown magma server. The correct way to do that is send #cleanUp to the MagmaSession class ? Then I would need shutdown squeak by command line but I will read how to do that. Thanks in advance, FV

2 1

Trying to understand forwarding proxies
by Norbert Hartl 03 Feb '11

03 Feb '11

After 4 years of abstinence from Magma I try to get back in touch to evaluate some new ideas. I was thinking how to utilize magma in a cloud environment like the one from amazon. So I'm interested in possible scaling scenarios. If I understand it correctly then - magma uses a directory to write its files. That could be called the repository - one repository is served by one server at any time - a special mode is possible where the client and the server reside in the same image (thus having only the need for a single image) - HA splits one node over certain locations. A node is an arbitrary amount of servers serving a single shared repository - forwarding proxies can be made from server to server. So these are cross-domain/cross-repository Talking to magma is done using a session. So I can do the following. - talk to a HA node that will read from an arbitrary server but will commit to a single one - mimicking a domain model by using forwarding proxies. So objects partitioned over multiple repositories appear to be in the same domain - using multiple sessions to read from multiple servers. That would be the case of domain model partitioning Up to here I would like to know what is the tradeoff in using forwarding proxies. Is the whole communication done via the proxy on the first machine or is another session created to which the client has direct access? Or to be more precise: If I would have a forwarding proxy to a collection in another repository that would hold objects from a third repository and I would detect: an object from that collection to which server am I talking when invoking a method on that detected object? As far as I remember sessions are not the most performant thing to establish. Do I remember that correct and has this changed? Same question goes for the start of a repository. Is this a quick operation or are there a lot of preparation steps that make startup rather slow? I hope these are not too much dumb questions. I'm just thinking about possibilities to what would be worth to try out. With amazon you can have multiple machines attached to a shared block storage. That can share all the repositories over an arbitrary amount of machines. But at the moment I can see how to get a lot of benefit from that particular feature regarding magma. If forwarding proxies are not too expensive that would be still enable some things. thanks in advance, Norbert

2 3

How to implement a messaging system?
by Amir Ansari 04 Jan '11

04 Jan '11

Dear list (I guess this follows on from my previous posts...) I'm trying to set up a simple messaging system using Magma, to enable users to pass messages to one another. I considered creating a 'mailbox' Collection for each user, in which messages could be stored, and which could be polled at regular intervals to check for new messages. However, since each session has its own view of this object, any other user/session dropping a message into the Collection would violate the rule 'do not share objects between MagmaSession instances'. What is the proper way to implement such a system? I'd be very grateful for any insight! Amir

3 5

Can't access objects in dictionary
by Amir Ansari 31 Dec '10

31 Dec '10

I enter the following code in a Workspace: (the class 'User' is just a very simple class with instance variable 'username' and corresponding accessors) MagmaRepositoryController create: '/testDB' root: Dictionary new. initialSession := MagmaSession openLocal: '/testDB'. initialSession connectAs: 'admin'. initialSession commit: [ initialSession root at: 'users' put: MagmaPreallocatedDictionary new ]. initialSession disconnect; closeRepository. newUser := User new username: 'Charlie'; yourself. newSession := MagmaSession openLocal: '/testDB'. newSession connectAs: 'charlie'. newSession commit: [ (newSession root at: 'users') at: newUser put: OrderedCollection new ]. newSession disconnect; closeRepository. testSession := MagmaSession openLocal: '/testDB'. testSession connectAs: 'aUser'. (testSession root at: 'users') size (testSession root at: 'users') at: newUser The last two lines indicate the problem: the size of the MagmaPreallocatedDictionary is reported correctly (even when I add more users), but when I try to access any of the entries with the 'User' objects as keys, I get a 'errorKeyNotFound:' error. Am I doing something wrong...? Amir

3 5

Re: Can't access objects in dictionary
by Amir Ansari 31 Dec '10

31 Dec '10

Hi Tim I'm using the User object as a key precisely because it's unique! Usernames will inevitably overlap. I considered email addresses, but if a user on the system changes their email address, it's an extra operation to update the Dictionary; with the User object, everything remains the same. Nevertheless, thanks for your reply! ;-) Amir On Thu, 30 Dec 2010 10:22:59 -0800 Tim Ziebart <timothy(a)churchmilitant.org> wrote: > I don't understand what you are trying to accomplish. I would have > expected the key to be a unique identifier such as username, email etc. > Then you would associate with the key a newUser. So, (newSession root > at: 'users') at: 'Charlie' put: newUser.

1 0

About MagmaPreallocatedDictionary
by Chris Muller 20 Dec '10

20 Dec '10

It is important to understand the nuances of using a MagmaPreallocatedDictionary. I must admit I intended it only for myself at the time I wrote it under a tight time-constraint; and so did not have time to develop what I really wanted.. Note the adjective, "Preallocated", it means all the hash-slots of the Dictionary are pre-allocated. This dictionary will not grow anymore. So this means there is a cap to how large it will scale before collisions are inevitable, which would rapidly degrade performance. Thankfully, the size of the support file on disk is actually only as large as needs to be to accommodate the *highest-used* hash value. Still, you will want to assume the highest-possible hash value could be used. It's 6-bytes per object-pointer so the file is 6 * [highest-used-hash-value] bytes in size. This makes the file on the server a many megabytes right out of the gate, but it won't grow again until a higher hash is used. It is absolutely _essential_ that you do not allow any identityHash to be part of your hash-calculation. Otherwise, it won't work; identityHash'es are unique between image sessions. Ultimately, MagmaPreallocatedDictionary will be deprecated. I would like to replace it with a new-and-improved MagmaDictionary based on the same concept (employing an underlying MagmaArray), but with a better hashing algorithm that allows expansion without rehashing the elements. - Chris

2 1

Report: upgrade to 1.2alpha and MagmaPreallocatedDictionary
by Timothy James Ziebart 16 Dec '10

16 Dec '10

Hi All, I wanted to let everyone know how it went. Environment: Linux Ubuntu 10.10, Seaside 3.0.2, Pharo 1.1.1. Monticello has not been updated with the latest Magma so I used the instructions Chris gave for loading the packages. I duplicated the list as follows: First load WeakOrderedCollection.2.cs.gz included on email from Chris announcing release of Magma 1.2 alpha1 - November 11, 2010. Ma exception handling-cmm.37 Ma base additions-cmm.187 Ma proxy support-cmm.44 Ma traverse object graphs-cmm.32 MaFixedWidthReport-cmm.7 Ma Statistics-cmm.24 Ma object serialization-cmm.245 Collections-BTree-lr.73 Ma special collections-cmm.116 Ma client server-cmm.217 WriteBarrier-cmm.28 Magma client-cmm.520 Ma contextual search-cmm.35 Magma server-cmm.418 Ma Armored Code-cmm.149 Ma Squeak domain-cmm.34 Ma special collections tester-cmm.14 Ma object serialization tester-cmm.33 Magma tester-cmm.372 Ran the upgrade on my existing database using instructions given by Chris in a previous email: please use the "Magma upgrader" package available on the "Magma tester" project of squeaksource. After loading it: (MagmaUpgrader source: '/path/to/old/repository') compressTo: '/path/to/upgraded/repository' Results: Packages loaded and upgrade went without a hitch. MagmaPreallocatedDictionary was then implemented replacing a standard dictionary keyed by region with each region holding a dictionary keyed by record id. My clients have to search a third party database with the results being updated with the data held in the magma database. The design was influenced by performance concerns. To reduce search time the client first selects a region and the dictionary associated with the region is loaded in effect loading only part of the database. The third party data is acquired and the records are then matched by a unique id on the dictionary now loaded. At this time there are only 30,000 region and record objects in the database (each object holds 10 fields containing strings and numbers totalling on average 200 characters). But with the standard dictionary loading the region dictionary took 7 seconds. After having implemented the MagmaPreallocatedDictionary the same operation takes LESS THAN A SECOND! The delay is imperceptible by the user. WOW, my next step is to test the performance by replacing the two tier dictionary to a single MagmaPreallocatedDicationary keyed on the record id. And thanks to Chris's comments I will be implementing a MagmaCollection on the same objects for performing descriptions and range searches. I must say I am impressed by Magma's reliability and the speed is not a factor -- the bottleneck is JQuery rendering! Thanks Chris. Tim

2 1

difference between MaDictionary and MagmaDictionary
by Esteban Lorenzano 15 Dec '10

15 Dec '10

Hi, I wonder what's the difference between MaDictionary and MagmaDictionary... and which should I use... is indistinct? Cheers, Esteban

5 13

MagmaRepositoryController error
by Amir Ansari 14 Dec '10

14 Dec '10

I'm getting an error trying to create a new repository; using Pharo 1.2beta (update 12272) and Magma 1.2alpha1, with WeakOrderedCollection. Workspace: "MagmaRepositoryController create: '/myDB' root: Dictionary new." Error: "Error: only integers should be used as indices" This certainly worked on Magma 1.1, but I was hoping to be able to use the new MagmaPreallocatedDictionary in 1.2... Should I post more detail about the error? Amir

2 2

Renaming persistent classes
by Chris Muller 13 Dec '10

13 Dec '10

>> Now I can proccess 1250 transactions from a csv file in less than 3 SECONDS >> including the time openning and proccessing of the file. Great! It's illustrative of the strengths of those two different parts of Magma. >> Other thing, after the refactoring I'm getting an error when I change >> anything on the class structure of any class. The error is: >> "MaObjectSerializationSoftwareError: Individual not defined in this image". >> That I did was rename two customer subclasses: >> Previous: >> Customer >> Individual >> Organization >> Now: >> Customer >> NaturalPerson (Persona Física) >> LegalPerson (Persona Jurídica) >> It's strange to me because now all seem works ok and because when I rename >> that classes haven't persistent instances on magma repository. >> >> Do you now that I'm doing wrong? Is it possible rename a persistent class? Yes, but you must do it under a transaction. Begin, rename, commit. If you didn't do it that way, then the repository will think it is just a new class and you will have to "upgrade" your old instances with a script. See MagmaTestCase>>testClassSchemaUpgrades. It includes a rename test. - Chris > The only person who can help you with this is Chris. Because my > knowledge about Magma in this area > are close to zero :) The other thing that can help everyone is the *code*. Answers to many questions are easily found there. It is straightforward, especially if you pay attention to the package each method is in; because that reveals what "layer" it operates on. - Chris

2 3

← Newer
1
...
7
8
9
10
11
12
13
...
73
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma