I knew about the methods needing to reside in the interpreter-per-thread, what I was unsure about is if the XoTCL methods are loaded into the interpreter separately from the object, but thinking about the ability to mixin objects and overlay object methods, that might not be going to work.
As you pointed out, the serializing of an object works very nice for caching purposes. But this does not allow me to access the object in multiple threads except through the single point of entry (in my example "get_instance_from_db"). So yes, if I want to instantiate an object from the DB and prohibit me going to the DB all the time, ns_cache works like a charm as I can instantiate the object in the current thread through "get_instance_from_db" from the one stored in the ns_cache instead of the db. But it's not the same as using the same object copy in memory, as each thread has it's own copy of the ns_cache object and I can manipulate each of them independently.
So, it is a TCL issue with not having a place to store variables and methods in a global, thread independent place, yet access it in each thread with the option to overlay it in each thread. Would ttrace help here (http://wiki.tcl.tk/2770) ? Probably not, because it still requires me to make the object known to the thread and creating a resource copy in that thread.
Thanks again for you answers, I understand the issue now much better and stay happy that I have the persistent "cross threads" tool called database to use .