> default isolation mode settings usually dont need any changes. we > dont have an official API for that yet, so you can apply it to all > connections using a custom connect() function sent to create_engine, > or you can try setting it individually as conn = session.connection(); > conn.connection.<set isolation>.
I've found that default postgres isolation level is `Read Committed Isolation Level` : http://www.postgresql.org/docs/7.4/interactive/transaction-iso.html but probably I need `Serializable Isolation Level` : """ The level Serializable provides the strictest transaction isolation. This level emulates serial transaction execution, as if transactions had been executed one after another, serially, rather than concurrently.""" ? > however, if youre getting that error, you either have a concurrent > process/thread already making an incompatible modification to the row, > *or* your mapping is not set up properly and the update isnt even > finding the correct rows to update....if the problem happens every > time, then the latter case is almost certainly the issue. you really > should view your SQL log to get a very clear idea of whats going on > and i doubt isolation modes are part of the solution here. Based on my observations it happens only with concurent inserts/ updates. One thread : {{{ f_table.insert().execute() session.flush() transaction = session.begin() nested = session.begin_nested() try: f_table.insert().execute() except IntegrityError: #record is exists and we got exception corresponding to contraint stuff = session.query(Path).select_from(..) ..update.. nested.commit() transaction.commit() session.clear() }}} Another thread: {{{ f_table.delete(...) #or update }}} > if you are getting genuine, occasional concurrent modification errors, > you can also look into using pessimistic locking, i.e. > query.with_lockmode(), to pre-lock rows inside a transaction and thus > prevent conflicts from occuring on the table in question. Could you please point on example of usage query.with_lockmode() ? By the way how is it working ? On changing table that is locked, SA will raise an exception or queries will be placed in queue for execution after transaction that locked table ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
