Marcus B?rger wrote:However it may be very usefull to terminate any open transaction before reusing a persisten connection. Typically this happens when the same script runs again. But anyway using transactions together with persistent conenctions in a multithreaded environment isn't the best thing you could do. So our options are 1) tell the users to do 'auto commit mode' 2) nested transactions 3) locking
>From my perspective 2) and 3) are bad ideas for the web environment. In other words i guess we should leave it as is with transaction rollback only when the client terminates (e.g. the webserver stops).
I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you pass the connection to a new client.
Right, and I don't see why using transactions in a multithreaded environment would be a bad idea. However an application is designed, one logical unit of changes, called a business transaction, has to have one database transaction modifying the business relevant information. There could be other transactions involved for dialog handling and advisory locking.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
