Re: TransactionManagementError is raised when autocommit …

Correction: > I can't use atomic blocks This is not true. "You can use atomic just over the section that causes the error", this has been suggested to me multiple times and I thought I had no use for it but it was actually very useful in many cases. With that technic and with the Django

Re: TransactionManagementError is raised when autocommit …

You can use atomic just over the section that causes the error. The issue is that different db engines have different semantics under error during transaction. Rolling back to the last savepoint (as atomic does when nested) recovers the ability to complete the remainder of the transaction. With a

Re: TransactionManagementError is raised when autocommit …

I recently upgrade Django 1.7->1.8 and ended up needing to patch set_rollback() and comment out the "exception if not in an atomic block" part. The problem was that sometimes database errors like IntegrityError occurred because multiple workers was trying to create the same data but that's

Re: TransactionManagementError is raised when autocommit …

On 11 Mar 2016, at 10:28, Tore Lundqvist wrote: > Given MySQL’s interesting approach to transactional integrity, you can call > transaction.set_rollback(False) after a query that failed with an > IntegrityError and keep going. > > You can't use set_rollback() outside an

Re: TransactionManagementError is raised when autocommit …

> Specifically, could you try adding `self.needs_rollback = False` at the > bottom of the `BaseDatabaseWrapper.rollback()` and tell me if that helps? > > Yes, this helps! With this change I can make it work without bypassing the public API. > > > > On 07 Mar 2016, at 12:55, Tore Lundqvist

Re: TransactionManagementError is raised when autocommit …

Hi Tore, I’ve been meaning to check whether your use case was supported, because it should be. I’m sorry, it took me a few days to find the time to investigate. While I was testing, I produced an exception which looks similar to the problem you originally reported:

Re: TransactionManagementError is raised when autocommit …

Hi, Shai As far as I know your not allowed to do a transaction.rollback() in an atomic block so I don't seen how this is different from doing a transaction.commit() Den måndag 7 mars 2016 kl. 08:23:09 UTC+1 skrev Shai Berger: > > Hi Tore, > > You should be able to get what you want be

Re: TransactionManagementError is raised when autocommit …

Hi, Aymeric Thanks for your extensive reply. I'm sorry that I just throw in that comment about timed out connections without enough information for you to actually respond to it. an example of when it happens is when: Starting with auto commit on. transaction.set_autocommit(False) ... a lot

Re: TransactionManagementError is raised when autocommit …

Hi Tore, You should be able to get what you want be replacing your commits by connection.cursor.execute("commit"); transaction.rollback() or equivalents (caveat: untested). This looks like a very hackish thing to do, code I wouldn't put in production. And it should. Shai. On

Re: TransactionManagementError is raised when autocommit …

Hi Tore, > On 05 Mar 2016, at 20:41, Tore Lundqvist wrote: > > Regardless of the particular problem I have got shouldn't it be possible to > disable Djangos transactional management if you want to? It's possible. It’s documented.

Re: TransactionManagementError is raised when autocommit …

Regardless of the particular problem I have got shouldn't it be possible to disable Djangos transactional management if you want to? Is not transaction.set_autocommit(False) doing that? Is it not surprising to get a TransactionManagementError when you have turned of the transaction management?

Re: TransactionManagementError is raised when autocommit …

Thanks for the suggestion! I have been thinking of workarounds with multiple db aliases and it would solve the problem I described but in reality the code I'm working with is much more complex and has around 400 explicit commits. It all worked great in Django 1.4 but since we upgraded to 1.8

Re: TransactionManagementError is raised when autocommit …

I've had this scenario before - you have two interleaving units of work (through composition of code from different sources or concerns). You want progress recorded for one unit of work, but perhaps not the other. Without django, you'd have two open connections. In my experience the simplest

Re: TransactionManagementError is raised when autocommit …

I don't what all updates to be in one commit each so I can't wrap just the update with a atomic block I would need to have it over a bigger chuck of code. That chunk might call a subrutin that also needs a commit and if I wrap that update in a atomic block that atomic block is nested and

Re: TransactionManagementError is raised when autocommit …

If you do what Simon and I suggest, you should get the result you just described. If you don’t, please explain what happens. Within a transaction — and disabling autocommit means you’re within a transaction — transaction.atomic() uses savepoints. Note that in Django 1.6, after

Re: TransactionManagementError is raised when autocommit …

Hi, Simon No, I would need to wrap everything i a atomic block to start the transaction and it's only when that outermost atomic block exits that I actually get a commit the nested ones just makes save point. /Tore Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes: > > Hi Tore, > >

Re: TransactionManagementError is raised when autocommit …

Hi Tore, Is there a reason you can't simply wrap your updates in a `transaction.atomic()` blocks? You should be able to avoid deadlocks and control exactly when data is written to disk with this construct. Simon Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit : > > Reply to

TransactionManagementError is raised when autocommit …

Reply to comments in ticket: https://code.djangoproject.com/ticket/26323#comment:10 Hi, @Aagustin: I get your point but in the code I'm working on there is a lot of transaction.commit(), not to handle transactions but to manage when data is written to disk and to avoid deadlocks. Running in