> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Beeton, Carolyn (CAR:9D60) > > > There could also be a problem in writing the file, since > > the separate > > > lock in each process does not guarantee that one process will not > > > begin to write the file while another is also in the process of > > > writing. > > > > That is true, but the actual replacement of the file > contents with the > > new file contents is done by a rename of the temporary > output file to > > the name of the real file, and rename is implemented > atomically by the > > kernel. > > > > I hadn't thought of that. In that case, I think the same > workaround that all the other DBs use will be adequate (i.e. > have the supervisor preload subscription.xml and > registration.xml). There is a lot of code in the various DB > constructors that just isn't doing what we expect > (initializing mTableLoaded to true, for example) - but it > will all be ok as long as one single process loads them > first. So I think I'll proceed with the other parts of this > and just leave the init mess the way it is. >
I've taken the easy way out then and just made supervisor preload subscription.xml. Code review at http://code.sipfoundry.org/cru/XECS-39 if anyone wants to comment. Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
