Hey Dmitriy,
2012/1/4 Dmitriy Igrishin <dmit...@gmail.com>:
> Well, suppose that the Transaction::~Transaction() looks like:
> Transaction::~Transaction()
> {
> if (std::uncaught_exception()) {
> // tries to rollback
> } else {
> // tries to commit
> }
> }
>
> And suppose My_class::~My_class() looks like:
> My_class::~My_class()
> {
> try {
> Transaction t(........);
> // some actions ...
> } catch (...) {
> // some actions ...
> }
> }
>
> Then,
> void f(......)
> {
> My_class obj(.....);
> throw 1;
> }
> Opps and ugh, because the transaction in the
> My_class::~My_class() will be rolled back because
> of stack unwinding instead of commit!
Okay, that's a case we hadn't thought of.
But is it realistic to start transactions in a destructor of a
stack-based object?
In either case, you can still add a t.commit(). In fact, I believe
that people will see more transactions rollback (I know I have)
because they forgot to commit() the transaction in each code path,
than this particular case (in which case you can still add the
explicit commit()).
Regards,
koen
------------------------------------------------------------------------------
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
