> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Edward Chowdhury > Sent: Wednesday, January 19, 2005 1:20 PM > To: [email protected] > Subject: RE: [CFCDev] Objects byReference > > On a slightly related note I've been implementing a system where the > navigation information for a site is stored in an application variable as > an > xml document. Whenever I need to get a particular section of the site, I > call a function that read locks the application variable and does an xpath > search of the xml document for that particular section and it's children. > So > here are my questions:
Personally I would recommend converting your XML to a collection of components for caching. XML is great for transferring and maintaining data, but I've always found it odd as a random access persistence source. You might just want to try it and see if there's any significant performance differences (there may not be). > 1) I use xmlSearch to return the section and it's child elements. Is the > xml > node returned a reference into the original xml document that is held in > the > application scope, or does xmlSearch actually duplicate all the nodes? I'm not sure, but I would suspect the latter. Since XML is really just plain text my guess is that it's making a string copy. However if CF is converting the packet to an object before working with it then it might be by reference. You should be able to test this easily enough: 1) Construct your cache. 2) In on template access a key (once, only once) and loop to display its value over and over several thousand times (you might want to also put a delay in there). 3) In another template read the same key and CHANGE its value several thousand times (run a count in a loop). Don't CFLOCK any of this and run both templates at the same time. If the first template reflects the changes made by the second then the value was passed by reference, otherwise not. > 2) If this xml node is being manipulated in the CALLING function (after > the > <cflock></cflock> code has already executed) is the xml element still > "protected" by the read lock? What would happen if the original XML > document > was deleted or changed while I'm reading and processing one of it's child > elements (keeping in mind that the application variable is no longer > locked > as I'm in a different function). If this is going to be a problem how do I > use and manipulate parts of a shared scope variable in a multiple calling > functions reliably? Perhaps. If the XML was an object (which I don't THINK it is) then it might work - you'd only be affecting the reference to the object. However this is where encapsulation really comes in handy. If you had one component (or a collection of components with a single root) that represented your data you could add methods (functions) to that component to do all your work. These functions would exist in the instance so they could "understand" when things were happening (for example you might set an instance variable in the component whenever somebody started a reading process or use a named CFLOCK. The "delete" method wouldn't delete the content if it were in use. > 3) This xml document is also streamed through flash remoting to flash > based > admin tools to create a hierarchy of the site so that they can embed links > to various pages in the site. Presumably it might take quite a few seconds > for the xml to finish streaming from the application variable to the > client. > What happens if the application variable is changed in the middle of this > process? Would this xml doc being streamed to the flash player not work > anymore? Is it even the same object that is being streamed to flash or was > a > copy made and sent onward? Again, if you encapsulate your code into a component you can control this: you can construct the component is such a way that the contents CAN'T be destroyed while streaming. You might still keep the data in your component as an XML packet - or not. It doesn't matter because you'd only be exposing those methods you want to, not the "raw" data. I may very well be missing the big picture here tho'. Jim Davis ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
