As far as aolserver cross-thread caching (or copying) for tdom objects is concerned, i must admit i cannot really image a case where this could really be useful. Parsing an xml-document with tdom is so fast, it usually takes only milliseconds, and performance-wise keeping the tdom document around simply does not pay.
But i must admit that my use-cases for xml-processing were mostly based on xml import and export of certain resources, so that the passing of tdom objects between pages was not necessary.
If you want to make up an xml document by integrating information from several html pages (wizard-style) and have an up-to-date tdom-document of the info around, i think the best way is to:
-create the xml doc on the first page
-for every user-input page
--read user info
--add user info to xml document
--write document to xml [$root_node asXML]
--cache this xml-source in memory
-on the next page recreate the xml-document from memory
-on the last page remove the xml-document from the cache
In my opinion, the only thing you could do to make sure that tdom commands are available to any aolserver thread is to create those documents in a special thread, dedicated to this task and interact with this thread from the request threads to get the tdom commands.
One thing i can recommed when dealing with complex xml-documents is to use xotcl. This object-oriented tcl add-on can be used within aolserver and makes processing of large xml-documents with deep hierarchies very easy. Objects can be aggregated (nested) and therefor you can keep the hierarchy of the document and deal with the data in memory.
The page that is most heavily used in my system shows multiplechoice questions to students (self-assessment). For that page i have to parse the xml-representation of the question, do some calculations with the data in it and read info from the database as well. I can easily save all that information in an xotcl-object-hierarchy, serialize that to tcl code, cache the tcl-code and recreate the whole hierarchy for the next access to the same question. No need to keep the tdom objects around :)
