I think you just aren't going to be able to reload the parent bean factory without screwing up your child applications. While both initialization processes are locked, they aren't the same lock. Thus, when you change the parent bean factory and the lock releases, the other applications are going to get mid-stream changes.
Remember, your parent bean factory is OUTSIDE the scope of ModelGlue, so I don't really know what ModelGlue can do about it. You are essentially pulling the rug out from running requests. Where MG gets involved is when the ModelGlue_PARENT_BEAN_FACTORY variable is set in ModelGlue.cfm. That is then pushed through an exclusive lock and the internal ColdSpring factory is created, with the ModelGlue_PARENT_BEAN_FACTORY attached in the parent spot. Since this is locked exclusively, it seems like this wouldn't be an issue. Have you possibly tried some way to put the new ParentBeanFactory in a different key in the application scope? Then passing the new key to the MG child apps for reload? DW On Mon, Nov 12, 2012 at 8:18 PM, Dan Wilson <[email protected]> wrote: > 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." > -- 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
