Hi Chris,
I'm studying the design of Magma hoping to glean some ideas for my own OODB implementation. The approach that you and I have taken are very similar in some respects, and very different in others. I have a few questions...
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?
How are you tracking the changed objects? It looks like there is some mechanism that you are using to track changed objects, but in the brief look I had, I couldn't see what you were doing. Are you just saving all client cached objects when a transaction commits?
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?
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?
Magma looks great...thanks and keep up the good work.
- Stephen