Soc, just checking in with you to see if you resolved your issue with unique app names and caching setting at the cfml engine level? I've definitely seen people running multiple versions of the same app on the same server by having unique cfml app name.
.pjf On Feb 23, 2011 4:36 PM, "Zack Pitts" <[email protected]> wrote: >> Basically every user will now do this in Application.cfc (and >> obviously make the change first thing upon SVN checkouts): >> <cfset this.mappings["/prog"] = "/home/webdoc/prog_dev#" /> >> <cfset this.name = "prog_dev#" /> > > No, don't hard code this. The devs will spend time switching this back > and forth in SVN as they overwrite each other (most likely showing as > code conflicts). Using something like the function I provided will > force all application mappings to be unique based on the name of the > directory where the code is running (you'll probably need to modify > the expandPath('/') to something more appropriate to your dev server > environment). That way no one ever has to change it for their own > purposes. > > >> Just so i understand what is occurring on the backend, i assume that >> "this.name" is what Coldfusion / MachII is using as an object cache >> header. So as long at the program names are different the users won't >> be sharing eachothers cache. Correct? > > The this.name value in the Application.cfc is what makes an > application's memory space unique on a server. So what's happening in > your situation is that everyone has the same application name, meaning > they are all sharing the same application instead of operating in > isolation. Creating a unique this.name programmatically based on the > directory where each dev places code will establish the isolation you > need. So, yes... different names means no sharing of the "cache." > > Another way to establish isolation is to run separate instances of > ColdFusion (in multi-server mode) on the dev server and map them to > each developer's code base. This may or may not be necessary, > depending on what your application is doing. > > >> Right now everything seems to be working okay, so all is hopefully >> well. Also thanks for the advice on a development configuration. >> Unfortunately, our local dev machines are a far different >> configuration than the production environment (Windows xp vs RHEL, >> MYSQL vs MSSQL), so i made the decision to have them develop remotely >> on a preproduction / dev server that had the same config as the >> production. > > Having a dev environment that is consistent with production will save > you numerous headaches down the road. If you have configuration > differences, then consider using virtual machines on your local dev > workstations and configure them with the correct OS and DB. This will > allow your devs to operate in a truly isolated manner, and will avoid > painful conflicts that may arise from running multiple instances of > the same app on a single server. > > Zack > > -- > Come see Team Mach-II at OpenCFSummit - Feb 21-23, Dallas, TX - http://www.opencfsummit.org/ > > To post to this group, send email to [email protected] > For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en > > SVN: http://svn.mach-ii.com/machii/ > Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/ -- Come see Team Mach-II at OpenCFSummit - Feb 21-23, Dallas, TX - http://www.opencfsummit.org/ To post to this group, send email to [email protected] For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://svn.mach-ii.com/machii/ Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
