> On Fri, 2009-04-03 at 17:02 -0400, Scott Lawrence wrote:
> > It should be calling the SubscriptionDB::getInstance(), which would
> > load it only if the database were not already loaded (which
> it should
> > be in every case, since the sipXsupervisor should have preloaded it
> > before your process was started).
>
> The code in question is a combination of rev. 14244 and 14584.
> Essentially, it sets up SubscriptionDB::mTableLoaded. When
> the SubscriptionDB object is created, the code will load the
> IMDB table from the persistent file if the observed number of
> users is 1 (that is, only the current process) or if
> mTableLoaded is 'false':
>
> 9999 xmlscott SubscriptionDB::SubscriptionDB( const
> UtlString& name )
> 9999 xmlscott : mDatabaseName( name )
> 14584 dworley , mTableLoaded ( false )
> 9999 xmlscott {
> 9999 xmlscott // Access the shared table databse
> 9999 xmlscott SIPDBManager* pSIPDBManager =
> SIPDBManager::getInstance();
> 9999 xmlscott m_pFastDB = pSIPDBManager->getDatabase(name);
> 9999 xmlscott
> 9999 xmlscott // If we are the first process to attach
> 9999 xmlscott // then we need to load the DB
> 9999 xmlscott int users =
> pSIPDBManager->getNumDatabaseProcesses(name);
> 14244 rjoly if ( users == 1 || ( users > 1 &&
> mTableLoaded == false ) )
> 9999 xmlscott {
> 14244 rjoly mTableLoaded = false;
> 9999 xmlscott // Load the file implicitly
> 9999 xmlscott this->load();
> 14244 rjoly // the SubscriptionDB is not
> replicated from sipXconfig, as
> 14244 rjoly // a result, make this table appear
> as being loaded regardless
> 14244 rjoly // of the load() result.
> 14244 rjoly mTableLoaded = true;
> 9999 xmlscott }
> 9999 xmlscott }
>
> Currently, mTableLoaded is initialized to false, which makes
> the constructor always load the table. Initializing
> mTableLoaded to true gives the behavior we want, but it also
> makes mTableLoaded useless. I suspect that mTableLoaded was
> intended to be set by a call to some IMDB routine, but I
> don't think we have that code.
I'm not clear on what is the 'behavior that we want' - what is broken
with the current behavior? The way it stands, the code will initialize
the subscription DB when the first user of the system tries to gets its
instance. That first user will always be sipXsupervisor. Having said
that, the way we use 'mTableLoaded' is strange for subscriptionDB. With
sipXconfig-replicated DBs, the state of mTableLoaded set in the c'tor
based on the result of the 'this->load()' operation but for the
subcriptionDB (and registrationDB), given that they are
process-initiated as opposed to sipXconfig-replicated, the result of the
load operation is not be taken into account to set the value of
mTableLoaded because for such databases, absence of the corresponding
xml file does not indicate a real failure or that initial replication
hasn't yet happened. However, the subscription c'tor code could be
cleaned up and also, default values should be provided for mTableLoaded
for all DB classes but that would not affect the behavior. I'll open a
minor tracker for that later today.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
