Questions

[Keith Hodges]

Chris,

I am trying to explain to myself how this all works in order to get my 
head around it. Would you be able to offer any insights on the following:

I have a repository which consists of one large fairly fully connected 
(i.e. many nodes have parent child bi-directional relationships) tree of 
objects, about 90000 at last count.

My web application begins by starting a seaside session, it then decides 
it needs some data from the repository, so it finds a MagmaSession on 
the repository and looks in magmaSession root for the start of its data.

At this point I assume that Magma rematerialises the root, and every 
object as it is needed by the application. For a single web page hit I 
expect to rematerialise 100 to 1000 objects, which seems like a good 
case for a ReadStrategy (another topic for another day).

Now this web application session hangs around in the web server 
referencing a bunch of these rematerialised objects. So I guess no 
clearing up happens yet. And if another user hits the web application, 
starting a new session, sharing the same MagmaSession, more objects will 
be loaded, and none cleared away.

However I notice that no one explicitly holds a reference to the root 
object, except for the MagmaSession itself, they are referencing other 
objects in the tree. Does this mean that if the model-tree was not fully 
connected, the root could be gc'd while the user continues to browse 
around the leaves? If so would a new user asking the same MagmaSession 
for its root, would get a fresh instance. If this new user browsed down 
to the same leaf as the first user, I would hope that they would both be 
looking at the same object within the one session.

If another user goes to the same leaf in a fresh second non-shared magma 
session then his root-tree and leaf objects are a different 
rematerialisation of the repository, they are not the same objects as 
the first two users are looking at. Is this the case?

So the first user changes the data in the leaf, the second user sharing 
the session with the first will see the exact same objects as the first 
so has no need to 'abort' to see the changes, in fact aborting is a bad 
idea because the first user may be in the middle of a commit:[] and that 
would ruin things for him.

The third user in his own magmaSession needs to #abort in order for the 
leaf object changes to be passed to his session. To see the changes I 
guess he has to let go of his own references to his view on the leaf 
objects, to back off to some safe unchanged place such as the branch, 
and then from there re-view the leaf objects which will have been 
updated. Is this correct?

Eventually the webserver is left alone for a while and sessions are 
discarded, I am assuming that the fact that the MagmaSession has a 
reference to its root will not stop it from being garbage collected. I 
also get the idea that it is not a good idea to store a reference to 
these persisted objects anywhere such as in a Class instance variable 
since this will simply result in the whole tree remaining memory resident.

.. to next email

best regards

Keith

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com