From: Timothy S. <ti...@op...> - 2006-04-20 07:49:03
|
Terry Macdonald wrote: > Billy G. Allie wrote: >> On Sun, 2006-04-02 at 19:25 +0100, Terry Macdonald wrote: >>> Billy G. Allie wrote: >>> > On Mon, 2006-03-27 at 13:52 +0100, Terry Macdonald wrote: >>> >> Hi, >>> >> [ . . . ] >>> > >>> If I have understood you then If I have a single cursor on a >>> connection I would need to do a commit after every select so that a >>> subsequent insert or update would have a correct timestamp. >>> Or... >>> I could have two connections each with a cursor; one >>> connection/cursor pair would be used for non-select statements and >>> the other connection/cursor pair would be used for selects >>> >>> Yes? >>> >>> >> Either would work (providing that the onnection/cursor pair used for >> inserts and updates is commited frequently enough to make the >> timestamps reflect the current time. >> >> /Note that the restrictions of one active transaction per connection >> is a PostgreSQL restriction, not a DB-API 2.0 compilant module >> restriction./ > I will be using a hack for now whereby for a non-select query a commit > is performed before and after execution as the cursor is also used for > select queries so a transaction is in progress pretty much the whole > time. > > Has no one else experienced this issue before? I'm surprised it > doesn't show up in the mailing list more often. Or am I doing things > completely arse about face! > > Do people open a new connection for every request?! surely not > > Thanks for your help Billy. > > the general useage of cursors i've seen is that they are short lived things you create for the purpose of one transaction and then closed. there is no reason really to leave them open when you can just leave the db connection open and create a cursor as you need it. thats the explaination i've seen on the psycopg lists anyway, and thats how i use it and i use a similar transaction based application, in which timestamps play a big role. |