Restart TG apps for high mem-usage

[Luke Macken]

On Mon, Nov 26, 2007 at 09:59:44AM -0800, Toshio Kuratomi wrote:
> Matt Domsch wrote:
>> On Sun, Nov 25, 2007 at 09:08:30PM -0800, Toshio Kuratomi wrote:
>>>> +1, but does it make sure all transactions are finished?  I know smolt
>>>> does not have good transaction protection.  If a transaction fails
>>>> halfway through, we might have a mess.
>>>>
>>> Not if the app doesn't.  From a brief test, TG apps do not do this.
>>
>> MirrorManager doesn't use transactions, I never figured out how to get
>> them to work right.  Advice welcome.
>>
> By not being able to get transactions working, do you mean explicit 
> transactions or implicit transactions?  I see that mirrormanager, bodhi,  
> and noc (not running currently) are using a dburi that disables implicit 
> transactions::
>   mirrormanager-prod.cfg.erb:
>     sqlobject.dburi="notrans_postgres://mirroradmin:
>     <%= mirrorPassword %>@db2.fedora.phx.redhat.com/mirrormanager"
>
> If that was changed to::
>   sqlobject.dburi="postgres://mirroradmin:[...]
>
> TurboGears would at least attempt to use an implicit transaction per http 
> request which should protect the database from shutting down the 
> application in the middle of processing a multi-table update.  I don't know 
> if that's the problem you're referring to, though.

Removing the notrans_postgres:// from bodhi's sqlobject.dburi causes
problems.  Modifications don't seem to go through; I'm not sure if they
hit the DB or not.  I remember encountering this issue early on in bodhi
development, and it was mitigated by calling hub.sync() all over the
place.  I have since removed them, and use notrans_postgres, which has
been working fine since day 1 of our production instance.  I'm not a
db guru, so I'm not sure which is better or worse.  I'll have to 
investigate this further.

luke