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
Howdy, you have some great questions here..
However I notice that no one explicitly holds a reference to the root object, except for the MagmaSession itself,
The MagmaSession only references the root if you ask for it while in a transaction.
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?
Yes.
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.
Yes, definitely. Each session has its own oid->object and object->oid identity maps. As the new user browses down to the object that references the same leaf held by first user, the oid reference in the buffer will cause it to "hook up" to the leaf object already previously materialised.
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?
Yep. Another user that has his own session has his own identity maps.
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.
Yes; as is committing a bad idea, since the other user might be in a commit (causing multi-level transaction confusion).
Everyone knows my opinion about sharing MagmaSessions among web sessions. It might be naive, I don't do web programming, but if someone is willing to try out the 1:1 design and experiences, I'd prefer to profile THAT and see where improvements can be made so as to maintain that simple design.
The third user in his own magmaSession needs to #abort in order for the leaf object changes to be passed to his session.
Yes.
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?
No. The leaf objects will be updated, in place, when the third user crosses a transaction boundary. No need to "expunge them" and "reload"; that would not be transparent enough.
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.
Unless the sessions still have a transaction open they do not hard-reference the root. Otherwise, yes, despite its reference to the root I think if the MagmaSession goes the root-reference would too.
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.
Yep, don't do that. :)
- Chris
magma@lists.squeakfoundation.org