Re: TransactionManagementError is raised when autocommit …

2016-03-19 Thread Tore Lundqvist
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 pat

Re: TransactionManagementError is raised when autocommit …

2016-03-14 Thread Tore Lundqvist
I can't use atomic block for reasons I tried to explain earlier in the thread. set_rollback is an advanced feature, should you not be able to use it in a db engine specific way/for mysql? Thanks for the feedback! -- You received this message because you are subscribed to the Google Groups "Dj

Re: TransactionManagementError is raised when autocommit …

2016-03-14 Thread Tore Lundqvist
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 ok,

Re: TransactionManagementError is raised when autocommit …

2016-03-11 Thread Tore Lundqvist
> 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,

Re: TransactionManagementError is raised when autocommit …

2016-03-07 Thread Tore Lundqvist
nit of work, but perhaps not the > other. > > > Without django, you'd have two open connections. In my experience the > > > simplest way to accommodate this is to have two DB aliases pointed at > > > the same DB. Set one to be a test mirror of the other

Re: TransactionManagementError is raised when autocommit …

2016-03-07 Thread Tore Lundqvist
Djangos transaction management for this code. Other parts of the system can use the transaction management as intended. Cheers Tore Den söndag 6 mars 2016 kl. 20:25:09 UTC+1 skrev Aymeric Augustin: > > Hi Tore, > > > On 05 Mar 2016, at 20:41, Tore Lundqvist > > wrote:

Re: TransactionManagementError is raised when autocommit …

2016-03-05 Thread Tore Lundqvist
ement? There is also another broken thing with set_autocommit(False) if the database connection has timed out and is reconnected by Django, autocommit is set to True again, that was kind of surprising and ugly to workaround. Den fredag 4 mars 2016 kl. 21:02:45 UTC+1 skrev Tore Lundqvist: >

Re: TransactionManagementError is raised when autocommit …

2016-03-05 Thread Tore Lundqvist
> one to be a test mirror of the other. Use different aliased connections > for the two concerns. Then you can use atomic (as suggested and typical). > > On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist > wrote: > >> I don't what all updates to be in one commit each s

Re: TransactionManagementError is raised when autocommit …

2016-03-04 Thread Tore Lundqvist
g autocommit means you’re within a > transaction — transaction.atomic() uses savepoints. > > Note that in Django 1.6, after set_autocommit(False), you couldn’t use > transaction.atomic(). That was fixed in 1.8 (I think). > > -- > Aymeric. > > On 04 Mar 2016, at 21:21

Re: TransactionManagementError is raised when autocommit …

2016-03-04 Thread Tore Lundqvist
gt; 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:

TransactionManagementError is raised when autocommit …

2016-03-04 Thread Tore Lundqvist
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 a

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

2016-02-24 Thread Tore Lundqvist
Is there something I can do to move this forward? Den torsdag 11 februari 2016 kl. 09:56:15 UTC+1 skrev Tore Lundqvist: > > Thanks for all the help with the patch! I hope its close to being > acceptable now. Can someone have a look at the PR? > > Den tisdag 2 februari 2016 kl.

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

2016-02-11 Thread Tore Lundqvist
Thanks for all the help with the patch! I hope its close to being acceptable now. Can someone have a look at the PR? Den tisdag 2 februari 2016 kl. 13:08:51 UTC+1 skrev Tore Lundqvist: > > Ok, got that sorted now. How about the fix, is it reasonable? > > > Den tisdag 2 februari 20

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

2016-02-02 Thread Tore Lundqvist
Ok, got that sorted now. How about the fix, is it reasonable? Den tisdag 2 februari 2016 kl. 11:51:19 UTC+1 skrev is_null: > > Just click "Details" and then "Console output". You'll find this: > > + flake8 > ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid > syntax >

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

2016-02-02 Thread Tore Lundqvist
Thanks for the feedback! I have updated the PR, can someone have a look at it again? I noticed that there where failing checks (flake8, isort) but it does not say why that it, do I need to fix something? Cheers Tore Lundqvist Den fredag 29 januari 2016 kl. 15:20:11 UTC+1 skrev Tore Lundqvist

Logged out sessions are resurrected by concurrent requests (ticket 21608)

2016-01-29 Thread Tore Lundqvist
Hi, everyone! I confirmed this (21608) non critical security bug a while ago and have sense then made a unit test and a fix for it. I have not gotten any feedback on my PR yet, is there something more I need to do to have someone look at this? Best Regards Tore Lundqvist -- You received this