[p4dti-discussion] P4DTI Database Management (CALL #1172709)

steve at vance.com steve at vance.com
Tue Dec 20 13:40:07 GMT 2005


And just re-do the initialization steps that depend on the database
connection each time or cache the results? It would move a significant
amount of the initialization into poll_start(). Does replicator rely on any
of the cached state directly or indirectly?

Steve

Original Message:
-----------------
From: Nick Barnes nb at ravenbrook.com
Date: 	Tue, 20 Dec 2005 13:10:22 +0000
To: p4dti-discussion at ravenbrook.com, support at perforce.com
Subject: Re: [p4dti-discussion] P4DTI Database Management 


At 2005-12-19 14:52:17+0000, Stephen Vance writes:
> I am creating a P4DTI integration with Roundup. The basic Roundup 
> installation, which is what my client is using, uses anydbm. Opening 
> the database holds a lock on the entire schema. Modelling the 
> integration after the Bugzilla implementation opens the database in 
> configuration() and it's implicitly closed on exit. This is necessary 
> for many of the initialization steps during configuration. However, 
> this will lock out any access to the issue tracker if it's run in the 
> standard mode with a sleep interval. It would be a significant 
> re-architecture to move the finalization of initialization to 
> dt_roundup.poll_start() in order to close the database in 
> dt_roundup.poll_end().

This is how I would do it.  Compare with how the database locking is
done in dt_bugzilla.py.  There's no particular reason why the database
connection need be maintained between polls; it's done that way in
dt_bugzilla because it's efficient.

Nick B
_______________________________________________
P4DTI-discussion mailing list
P4DTI-discussion at ravenbrook.com
http://mailman.ravenbrook.com/mailman/listinfo/p4dti-discussion


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .





More information about the P4DTI-discussion mailing list