Yeah, I can see what you mean. However, I have no idea how to make that threadsafe, since multiple threads are accessing it.
I'm open to ideas. DW On Mon, Nov 12, 2012 at 7:23 PM, Brian G <[email protected]> wrote: > > That's what I'm doing: > > <cfif NOT structKeyExists(application, "cs") OR structKeyExists(URL, > "reinit")> > <cflock name="applicationReinit" type="exclusive" timeout="60"> > <cfif NOT structKeyExists(application, "cs") OR structKeyExists(URL, > "reinit")> > .... > > <cfset bf = createObject("component", > "coldspring.beans.DefaultXmlBeanFactory").init() /> > <cfset > bf.loadBeansFromXmlFile(expandPath("/PUKKA_MAIN_MAP/config/globalbeans.xml"), > true) /> > <cfset application.cs = bf /> > > </cfif> > </cflock> > </cfif> > > I think the problem is... this code runs, and it gets down to index.cfm > which sets: > > <cfset ModelGlue_PARENT_BEAN_FACTORY = application.cs /> > ... > <cfinclude template="/ModelGlue/gesture/ModelGlue.cfm" /> > > I think this is the part that's not thread safe. Imagine that I have a > request that's taking 5 seconds to run, so the code is already down to > index.cfm and running a model glue request. > > Now, in another window, I reinit the beanfactory using the above code and > it gets down to this line of code. When ModelGlue.cfm runs, it's going to > update the Parent Beanfactory in the Model Glue object cached in the > application scope. > > As soon as that happens, the next line of code in my 5s running thread now > hits a new version of the parent beanfactory (and presumably ORM/Transfer > or whatever your service layer abstracts). Things then begin blowing up. > > > Brian > > > > On Thursday, November 8, 2012 11:31:40 AM UTC-8, Dan Wilson - > [email protected] wrote: > >> Well, let's think about this. >> >> Set Parent, expects a fully hydrated bean factory to be in place and get >> handed to MG. Which makes sense, because ParentBeanFactories may/usually >> service more than one MG application instance. So MG couldn't reload the >> bean factory on it's own, without screwing over other (potential) MG >> instances. >> >> >> So, I'd say it is thread safe as long as your reload functionality for >> the parent bean factory is thread safe. >> >> >> >> Would it be possible to do something like this? >> >> if( reloadBeanFactory){ >> >> --Lock-- >> var newBeanFactory = createNewParentBeanFactory; >> application.parent_bean_**factory_for_model_glue = newBeanFactory; >> --Unlock >> >> } >> >> >> That would minimize the time the parent bean factory is stale. When you >> have it fully hydrated, then replace the application instance with the >> newly instantiated one. >> >> >> Thoughts? >> >> >> >> DW >> >> Brian G >> Thursday, November 08, 2012 2:23 PM >> >> On Thursday, November 8, 2012 9:19:56 AM UTC-8, Dan Wilson - >> [email protected] wrote: >> >> I don't disagree per se, but since this is the general design paradigm of >> a parent bean factory and continuous deployment and/or code pushes without >> interrupting users is a significantly valuable goal, I think we should look >> at it. >> >> I think the problem is that MG's setParent() for the parent_bean_factory >> is not thread-safe. >> >> I'm trying alternative approaches today using onApplicationStop() but >> that results in even more weirdness. Request scope variables set in a >> controller don't exist when I get to a view template... I'm going to try to >> start at the beginning, load testing each step, and see where I can get >> to. Also might see if I can setup a basic MG app and demonstrate it there >> too. >> >> >> Brian >> -- >> Model-Glue Sites: >> Home Page: http://www.model-glue.com >> Documentation: http://docs.model-glue.com >> Bug Tracker: http://bugs.model-glue.com >> Blog: http://www.model-glue.com/blog >> >> You received this message because you are subscribed to the Google >> Groups "model-glue" group. >> To post to this group, send email to [email protected] >> >> To unsubscribe from this group, send email to >> model-glue+...@**googlegroups.com >> >> For more options, visit this group at >> http://groups.google.com/**group/model-glue?hl=en<http://groups.google.com/group/model-glue?hl=en> >> Dan Wilson >> Thursday, November 08, 2012 12:19 PM >> One way to look at this is the parent bean factory is not controlled by >> ModelGlue. It's expected this will be instantiated and passed to Model >> Glue. (Look in ModelGlue.cfm) >> >> Reloading the Parent Bean Factory is the responsibility of the parent >> bean factory control mechanism. So, if you need to restrict access to this, >> you need to do it in the location where you reload your parent bean factory. >> You may consider creating your new beanfactory in a separate application >> variable, then switch it over when it is instantiated. But as it stands, I >> don't see how MG can get involved with this process, because the parent >> bean factory lives inside a different context. >> >> >> DW >> >> >> Brian G wrote: >> Brian G >> Thursday, November 08, 2012 9:57 AM >> >> On Wednesday, November 7, 2012 5:48:24 PM UTC-8, Dan Wilson - >> [email protected] wrote: >> >> Correct - the exclusive named lock only prevents duplicate >> initializations; it doesn't do anything related to non-reinit MG requests >> from accessing values/objects that are changing during the initialization >> like the parent bean factory. >> >> We need a method of telling MG to lock/unlock access to the parent bean >> factory while we reinit it. An exclusive lock on the app scope might do >> it? I don't know if that would be hard to obtain in practice in production >> or if it would just cause a lot of timeouts? >> >> Brian >> >> -- >> Model-Glue Sites: >> Home Page: http://www.model-glue.com >> Documentation: http://docs.model-glue.com >> Bug Tracker: http://bugs.model-glue.com >> Blog: http://www.model-glue.com/blog >> >> You received this message because you are subscribed to the Google >> Groups "model-glue" group. >> To post to this group, send email to [email protected] >> >> To unsubscribe from this group, send email to >> model-glue+...@**googlegroups.com >> >> For more options, visit this group at >> http://groups.google.com/**group/model-glue?hl=en<http://groups.google.com/group/model-glue?hl=en> >> Dan Wilson >> Wednesday, November 07, 2012 8:48 PM >> >> I believe that takes place in ModelGlue.cfm >> >> The lock is exclusive and is double checked as is best practice. >> >> However, I don't believe your parent bean factory is under that same >> lock. So when you remove that bean factory, it's out of the protected zone, >> thus problems arise, no? >> >> Dw >> Brian G >> Wednesday, November 07, 2012 8:31 PM >> >> Let's say you have application.cs which is your PARENT_BEAN_FACTORY. >> >> You have 10 other users hitting the site, they are in the middle of a >> request to index.cfm which is using an already-initialized Model-Glue and >> they are happily processing requests. >> >> Now, I start the process of ?reinit=true which in my OnRequestStart, >> first calls onApplicationStart() (or just recreates application.cs) and >> then subsequently re-initializes Model Glue. >> >> But, the nanosecond application.cs is reassigned, the other 10 users with >> in-progress requests piped through Model-Glue to the service layer begin >> acting crazy because, as you correctly point out, the beanfactory to which >> MG has a reference no longer exists. >> >> We need some way of locking model-glue from performing a request while we >> recreate the bean factory and assign it. >> >> >> Brian >> >> >> On Monday, November 5, 2012 4:45:46 PM UTC-8, Dan Wilson - >> [email protected] wrote: -- >> Model-Glue Sites: >> Home Page: http://www.model-glue.com >> Documentation: http://docs.model-glue.com >> Bug Tracker: http://bugs.model-glue.com >> Blog: http://www.model-glue.com/blog >> >> You received this message because you are subscribed to the Google >> Groups "model-glue" group. >> To post to this group, send email to [email protected] >> >> To unsubscribe from this group, send email to >> model-glue+...@**googlegroups.com >> >> For more options, visit this group at >> http://groups.google.com/**group/model-glue?hl=en<http://groups.google.com/group/model-glue?hl=en> >> >> -- > Model-Glue Sites: > Home Page: http://www.model-glue.com > Documentation: http://docs.model-glue.com > Bug Tracker: http://bugs.model-glue.com > Blog: http://www.model-glue.com/blog > > You received this message because you are subscribed to the Google > Groups "model-glue" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/model-glue?hl=en > -- Plutarch - "The mind is not a vessel to be filled but a fire to be kindled." -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
