links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Magma Answered
Last updated at 4:47 pm UTC on 28 December 2012
mergeMe into Magma

Does MagmaServer deliver an object to a client upon request?

If it does, in what format will the object be delivered?

If it does not, would you consider this as a feature request?

Q: I notice that you are assigning oids to every object that is stored in Magma and using a WeakKeyIdentityDictionary for storing the oids. One issue I had with that approach is that I think it runs into scalability issues when you approach and surpass 4096 objects (due to the number of bits available for the identity hash). Is there a way to make this scheme more scalable? Or, is it possible that it will be rare to have more than 4000 persistent objects cached on the client?

Q: How are you tracking the changed objects?

For objects which cannot use the WriteBarrier method, their original Buffers from the read are kept around for as long as the object is referenced in memory. When a commit occurs, the objects are compared to their original buffers to determine whether any changes occurred.

It takes a long time to establish a MagmaSession (especially after some objects have been populated in the server)...can you describe what's happening when connecting?

I see that you are using a stubbing mechanism (ala GemStone) that uses a ProtoObject and #doesNotUnderstand: to transparently forward messages to the real object. Are you also using #become: to change these objects into their real counterpart? If so, won't this present a performance issue under certain circumstances (where one or both of the objects are in old space)? Also, did you implement a "stubbing level" mechanism ala GemStone?

In addition to this, the number of becomes: can be reduced by setting a ReadStrategy on the Session. Magma, by default, reads +1 level deep whenever it reifies a proxy, leaving references at +1 level down also proxies (unless they cycle back to a "higher" place in the model which had already been retrieved, of course). But this is a balancing act, since it also means that the Read's will be larger and take longer.

For OLTP applications, +1 level is generally fine for end-user performance expectations.

Is there any kind of cache control in Magma? For example, if I have a client that is running for many weeks and accessing lot's of objects, once they are pulled from the server to the client, are they going to stay in the client indefinitely? Is there some way of controlling how many objects are retained in the client's object memory?

Yes, any object can be converted back to a "stub" (Proxy) by telling it to #stubOut:.