On Monday 22 October 2001 07:20 am, Oliver Erlewein wrote:
Hi everybody
Try this from the root Folder:
<dtml-var standard_html_header> <dtml-in "[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 ]"> <dtml-in "ZopeFind(this(), '', '', '', '', '' , '', '', '', 1)" sort=bobobase_modification_time reverse> <dtml-var bobobase_modification_time>, <dtml-var id><br> </dtml-in> </dtml-in> <dtml-var standard_html_footer>
This should take a while to show. If not try more 1,1,1,....! If I call another page on a second browser window on the same Zope-site the response is generated after the above script is completed. This would mean that the script hoggs all threads.
actually it doesn't but it is good example of some zope's optimization. so whats happening here is that ZopeFind starts looking through all the objects of the folder trying to match up requirements, when it does that it means that all these objects are now loaded from the db and are in memory/cache. after the page gets served back to the client the zpublisher thread releases its connection to the zodb, this connection's cache contains all those objects just loaded. when another request is served the zpublisher thread opens up a connection to the zodb, internal to the db these connections are stored in a FIFO stack, so the zpublisher thread ends up getting and using the connection with all those objects sitting in cache, now when the find executes it basically is operating on objects that are all in memory! cheers kapil