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.
>
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
relevantinformation.
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. #
#================================================== JanWieck@Yahoo.com #
