2012/1/3 Dmitriy Igrishin <dmit...@gmail.com>
>
>
> 2012/1/3 Dmitriy Igrishin <dmit...@gmail.com>
>
>> Hey Koen
>>
>> You're right. As you observed, we've added a new feature to
>>> transaction handling (a hint from Bart Vanhauwaert): to auto-commit
>>> transactions when the transaction object destructs if the destruction
>>> is not a consequence of an exception being thrown (I was unaware that
>>> C++ actually has a function for detecting that:
>>> std::uncaught_exception()).
>>>
>> I think that more correct way to detecting that is to use
>> transaction status, returned by the backend. In case of
>> Postgres (libpq) its a function PQtransactionStatus().
>>
> By the way, in PostgreSQL any transaction block may be
> closed by COMMIT command -- the transaction is doomed
> on ROLLBACK if some command within it cause the error:
> dmitigr=> BEGIN;
> BEGIN
> dmitigr=> SELECT version();
>
> version
>
> ----------------------------------------------------------------------------------------------
> PostgreSQL 9.1.0 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
> 4.6.1-4) 4.6.1, 64-bit
> (1 row)
>
> dmitigr=> BAD_COMMAND;
> ERROR: syntax error at or near "BAD_COMMAND"
> LINE 1: BAD_COMMAND;
> ^
> dmitigr=> SELECT version();
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block
> dmitigr=> COMMIT;
> ROLLBACK
>
> So, there is no need to perform ROLLBACK explicitly
> (in case when the descruction of the transaction object
> performed by the stack unwinding).
>
>>
>>> The upshot is: you no longer are required to explicitly commit() all
>>> your transactions -- this is now the "default" behavior.
>>>
>>
>> Really good idea.
>>
> Although, there is one serious drawback with
the idea of "auto-commit" transactions -- the
"COMMIT" SQL command performed during the
deletion of the Transaction object (from
the destructor) may fails by some reasons. But the
user may wants to know these reasons and the
user usually wants to be sure that the transaction
*really* committed by the backend. So, the only
way to inform the user about an error is to throw
an exception from the descructor which seems to
me as a very bad design approach, since as all we
know, exceptions should not leave destructors.
I propose the "auto-rollback" on descruction instead
of "auto-commit" which seems to me more safe.
--
// Dmitriy.
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
