I use DBSession.begin() with the subtransactions flag to catch a flush error for a particular operation when I have a sequence of operations.
You might want to check the following URL for sections on "transactions", "savepoints", "managing transactions" http://www.sqlalchemy.org/docs/orm/session.html If you would like to debug this further, you might want to : (a) look at your $project/model/__init__.py (to see what arguments are used to create the DBSession) (b) i doubt that the entire DB is locked for a transaction (c) you could trying creating your own separate Session object and use it in your cron job. I suspect (c) might work for you. On Dec 10, 6:02 am, alonn <[email protected]> wrote: > thx > but I need some explanations: > since this is a cron job (using tg.scheduler) I'm not in the > controller > > you suggest before every commit I'll do DBSession.begin then > DBSession.add(object) ,then DBSession.flush()? > > but how do I catch the FlushError? with out ending the transaction. If > I don't handle it someway every flush after fails because sqlalchemy > is waiting for a rollback > if I catch the error with DBSession.rollback() the transaction is > broken - is this why you call DBSession.begin()? would calling > DBSession.begin() after it is already started would raise an > exception? > On Dec 9, 8:30 am, ozwyzard <[email protected]> wrote: > > > > > > > > > If possible, try wrapping your code around this. > > > try: > > DBSession.begin(subtransaction=True) > > <DB statements> > > DBSession.flush() > > except FlushError, e: > > raise <CustomError> > > > I use the above method for forcing a check for DB consistency within > > the controller, as opposed to at the exit point. Let me know if this > > helps. > > > On Dec 4, 6:32 am, alex bodnaru <[email protected]> wrote: > > > > On 12/04/2011 11:35 AM, alonn wrote:> thx alex - but I still have a > > > problem > > > > since I'm currently calling the db update procedure (which does the > > > > dbsession.flush) - as a cron job and not through a controller (which > > > > would be added later - but only for monitoring purpose) > > > > So how can I release the transaction (or dbsession?) handle on the db > > > > when the procedure finishes? > > > > dbsession.commit() after the .flush(). usually ;) > > > > > On 4 דצמבר, 05:32, alex bodnaru <[email protected]> wrote: > > > >> hi alon, > > > > >> On 12/02/2011 10:32 PM, alonn wrote: > > > > >>> in my turbogears application I'm writing to an mssql db with > > > >>> DBSession.flush() - this is a cron initiated method > > > >>> but after the commiting is made (my guess is transaction commit > > > >>> somewhere behind tg2.1 curtains) the db table is locked to access from > > > >>> another file (the main file that uses that db.. ) until I kill the tg > > > >>> application. > > > >>> I read that I can use transaction.doom() but I think that would also > > > >>> rollback the session (which I don' t want to - I just want to close > > > >>> the session ) and I don't know how this would influence the whole > > > >>> application (would tg bring it back to live next time I use DBSession? > > > >>> etc) > > > > >>> I'll be glad to some help here > > > > >> a transaction is being begun before your controller method is being > > > >> invoked, for > > > >> every dbsession you have in your model. > > > >> if no exception occurs in your controller method, all these > > > >> transactions are > > > >> being committed after your controller method ends. > > > >> you may dbsession.flush() at the point you want, disregarding the > > > >> transaction > > > >> commit that will follow. > > > >> you may begin your controller method with transaction.doom() or > > > >> .commit(), so > > > >> your code will not run in the transaction above. this will free your > > > >> hands to > > > >> begin, doom (rollback) and commit wherever you choose. > > > > >>> 2.another small question - how do I control when the db transaction > > > >>> is being commited? since I iterate through a list of object, and in > > > >>> each one using DBSession.flush but the actuall commiting occures only > > > >>> when the iterating is over , my guess is the transaction.commit() is > > > >>> somehow called and all the new objects are commited to the db. can I > > > >>> control when this commiting is made? > > > > >> hth, > > > >> alex -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
