Hi Stephen, let me see if I can answer your 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?

A:  I don't think it would be "rare" to have more than 4K objects in a
medium-sized program.  However, it was written with the expectation that
identityHash will be fast.  If there is a scalability problem w/
weakIdentityDictionaries greater than 4K in size, then there may be a
scalability issue w/ Magma.

======

How are you tracking the changed objects?
A:  Take a look at MaTransaction>>markRead:.  MaTransaction maintains an
IdentityDictionary whose keys are the read object, values are a shallowCopy
"backup".  When you commit, it zips through the keys and values and does an
identity compare of each objects variables (see implementors of
maIsChangedFrom:).  This may seem like a lot of work, but its actually
suprisingly fast.  Additionally, I prefer this "copy and compare" method of
change detection because it offer the most transparency.

========

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?
A:  Hmm... I've never noticed that taking a long time.  If you look at the
MamgaSession>>connectAs:maximumNumberOfChallengers: it summarizes what happens
upon connection.  Basically, we have to get the classId's and definitions of
all the classes that are known to the repository.  The current class definition
defined in Magma has to match what is in your image or it won't let you
connect.

I haven't posted the Swiki page yet about how to tell Magma to "upgrade" a
class to a new version, but you can see examples in MagmaTestCase.

==========

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?
A:  I use becomeForward:.  I've not noticed any performance issues in my
"small" volume tests.  If this causes a performance problem due to them being
in oldspace, do you have an alternative?

========

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?

A:  The only "caching" Magma does is in weak collections, so there shouldn't be
anything that you don't cache yourself.


Regards,
  Chris

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com