14 Sep
2006
14 Sep
'06
4:29 p.m.
about MADynamicObject and serialization.
It is used to put a calculated value into a variable.
Whenever you
send the first message to it, the block gets evaluated and the
This is the bit that I dont understand, I cant see where the
'evaluation' actually happens. Who does it? Where is the code that says
'aBlock value'?
What I find strange is that a MADynamicObject is
ending up in the
code to serialize.
Before persisting a PRContext, I was zapping its properties to
nil.
However I had omitted to do the same to the context's command's answer
context, as in the case of a PRAddCommand. So it was in the dictionary
of properties, containing references to components that was causing the
problem. Exactly where WAProxyObject is in there I am not quite sure
since I never got a proper debugger up on it. The
PRCommandAdd-structureClasses appeared to be the one causing trouble,
i.e. a reference to this dynamic object is contained in one of the
components.
----
So now Pier-Magma is looking good to go. My main objective was to be
able to have the Pier data persisted outside of the image so that an
'upgrade' of the image would be straightforward.
There are (at least) two more issues to consider if Magma-Pier is to be
a tour-de-force.
1) At the moment pier-magma marks objects for rematerialisation as
needed, one-by-one. Magma can be configured for different
read-strategies, so performance could be greatly increased (so I am
told) if the read strategy re-materialised on a page-by-page or
kernel-by-kernel basis (for a multi kernel site).
2) Using a non-shared MagmaSession takes time to get the initial session
on the database (it could hold a cached session ready in order to
improve this), but when the session is expired the objects may be free
to be purged from the image. (Thinking about it I suspect that this will
not happen automatically with my current implementation, but it should)
My current preferred approach is to use a shared MagmaSession where
there is only one MagmaSession for all the seaside sessions. Effectively
this caches every used object in memory, and the opportunity for
allowing objects to be purged/gc'd is less clear. I am assuming that
Magma doesnt do an explicit purge, but relies upon the application to
'let go' of unneeded objects for gc to tidy up.
Keith
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The
Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html