Marcus B?rger wrote:
> Hello Jan,
>
> Tuesday, July 22, 2003, 10:57:56 PM, you wrote:
>
> JW> Bruce Momjian wrote:
> >> 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.
> >>
>
> JW> Right, and I don't see why using transactions in a multithreaded
> JW> environment would be a bad idea. However an application is designed, one
> JW> logical unit of changes, called a business transaction, has to have one
> JW> database transaction modifying the business relevant information.
> JW> There could be other transactions involved for dialog handling and
> JW> advisory locking.
>
>
> So i'll update to "BEGIN;COMMIT;RESET ALL;" :-)
Yes, I think that is it. The RESET ALL has to be at the end because you
have to make sure the RESET is in a valid transaction.
The only way to make sure autocommit doesn't effect you would be to do:
BEGIN;COMMIT;BEGIN;RESET ALL;COMMIT;
but the autocommit GUC option was only in 7.3 and will not be in 7.4, so
this seems like overkill.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
