Re: #13870: Correctly handling database isolation (in PostgreSQL)

On 07/09/10 14:05, Patryk Zawadzki wrote: > Not deprecated in Django sense. I don't think it's going away any time > soon. Just that it's been discouraged for a while at the > psycopg/database level. Well, maybe "discouraged" is fair, but it does exist and you have the option (and if you use

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On 07/09/10 16:16, Robert Gravsjö wrote: >> with db.isolation(ISOLATION_SERIALIZABLE): >> # ... >> > > You don't want to serialize access to the database in a multi-user > application. Just in case: serializable transaction != serializing access - among serializable level transactions,

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki skrev 2010-09-07 16.47: On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki wrote: It would be more useful if you could explicitly enter_isolation_block() and leave_isolation_block() as needed (currently there is no way to commit the isolating transaction

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki wrote: > It would be more useful if you could explicitly > enter_isolation_block() and leave_isolation_block() as needed > (currently there is no way to commit the isolating transaction other > than doing a raw SQL query or

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Tue, Sep 7, 2010 at 2:57 PM, David De La Harpe Golden wrote: > On 06/09/10 14:29, Patryk Zawadzki wrote: >> The problem only exists when Django sets isolation level to 1, if you >> use the deprecated "autocommit" setting, you will not be affected. > Uh. Is this

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On 06/09/10 14:29, Patryk Zawadzki wrote: > The problem only exists when Django sets isolation level to 1, if you > use the deprecated "autocommit" setting, you will not be affected. > Uh. Is this deprecated? At what layer? Since when? I've been using it* happily for a while (modulo that one

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Tue, Sep 7, 2010 at 8:29 AM, Thomas Guettler wrote: > If you have a daemon that lives forever, I would do it like this (untested > if this does not leave an idle transaction open): > The place where the daemon hangs around if nothing can be done lives must > not use the ORM.

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki wrote: > On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote: >> Patryk Zawadzki skrev 2010-09-06 15.29: >>> The isolating transaction keeps going on until you either (1) commit, >>> (2) rollback or (3) disconnect. Django only commits/rollbacks the >>>

Re: #13870: Correctly handling database isolation (in PostgreSQL)

I ran into this issue with daemons/scheduled jobs and "idle in transaction" in Django quite a while ago. I have a nice writeup of the problem and solution on this StackOverflow question if anybody's interested:

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote: > Patryk Zawadzki skrev 2010-09-06 15.29: >> The isolating transaction keeps going on until you either (1) commit, >> (2) rollback or (3) disconnect. Django only commits/rollbacks the >> transactions it explicitly starts, it

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, 2010-09-06 at 16:47 +0200, Robert Gravsjö wrote: > Can you please show me the code you're running to reproduce this? > > Regards, > roppert I've experienced what Patryk is describing here. It seems that the Django ORM, when not explicitly in a transaction, doesn't commit or rollback

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki skrev 2010-09-06 15.29: On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote: I'm not sure what you think you are doing but if you end up with " in transaction" that means you have not commited your transactions. See below. For instance, open two

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote: > I'm not sure what you think you are doing but if you end up with " >  in transaction" that means you have not commited your transactions. See below. > For instance, open two connections with psql and run BEGIN in one and >

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki skrev 2010-09-06 12.20: On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess) wrote: --- snip --- You can check this by creating a fresh project using psycopg2 and creating a model. Then write a view that queries the database and

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 1:35 PM, burc...@gmail.com wrote: > Hi Patryk, > > This was done to make Django faster, so it doesn't create connection > to database every time new SQL is executed. What was done? Commiting the isolating transaction of a connection does not terminate

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Hi Patryk, This was done to make Django faster, so it doesn't create connection to database every time new SQL is executed. Do you mean you wanted to set up timeouts for idle database connections? I guess, nobody asked this before. On Mon, Sep 6, 2010 at 5:20 PM, Patryk Zawadzki

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess) wrote: > Strange. We use Postgres and don't see any problem with this. We do > encounter complications occasionally with the lack of composition of > Django transaction handling, but other than that find the

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Strange. We use Postgres and don't see any problem with this. We do encounter complications occasionally with the lack of composition of Django transaction handling, but other than that find the transaction handling adequate. Are you actually using transactions in your code? You need to be. The