That was a super interesting discussion :)
My 2c is .. I can see both points of view. It is one more thing to add to
the learning curve of Wt.
It may break some existing code that relies on the default rollback
behaviour.
For example:
void save() {
dbo::Session&s = getSession();
dbo::Transaction t(s);
dbo::ptr<BlogPost> post = getPost();
post->setTitle(_title->textValue());
if (user->hasWriteToUpdate(post)) {
t.commit();
}
}
I'm thinking there may be some checks you'd want to do during a
transaction, that may inolve more DB queries. Of course this could be
written instead:
...
if (!user->hasWriteToUpdate(post)) {
t.rollback();
}
...
So in summary, I guess its up to the dev team to weight up the pros and
cons:
pros:
- Less typing to get default / most commonly desired behaviour
- User can still be explicit and use t.commit() and t.rollback()
cons:
- May break existing code that relied on old behaviour
- Adds to the Wt learning curve
neutral:
- Allows lazy/tired/dummy programmers to accidentally get it right most
of the time, when they forget to close the transaction (most of the time).
Rather than having to go through their code and figure out why it didn't
save.
Personally I think it's a good idea :) but I'm still gonna continue using
explicit commit() and rollback() in my code :)
Sorry my 2c is so big :D
On Wed, Jan 4, 2012 at 9:33 PM, Dmitriy Igrishin <dmit...@gmail.com> wrote:
>
>
> 2012/1/4 Koen Deforche <k...@emweb.be>
>
>> 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?
>>
> Yes, it is. At least in PostgreSQL, each command
> that is performed out of the explicitly opened transaction
> block runs in the separate transaction. There are
> a lot of commands which are intended to free resources
> on the server side, such as cursors (CLOSE command),
> savepoints (RELEASE SAVEPOINT command),
> listeners (UNLISTEN command), the DISCARD command,
> or even the applications specific (advisory) locks.
>
>>
>> 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()).
>>
> Yes, but personally I think that this makes the API more
> complex and error-prone, since the user must know about
> a gotcha which I mentioned above.
> Anyway, it is just my point of view, if you don't see the
> problem here and you sure that the users need this feature,
> I don't mind.
>
> --
> // 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
>
>
------------------------------------------------------------------------------
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
