[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