Re: [Engine-devel] Global transaction in ovirt-engine

From: "Liron Aravot" <laravot(a)redhat.com&gt; To: "Michael Kublin" <mkublin(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Tuesday, February 12, 2013 1:08:07 PM Subject: Re: [Engine-devel] Global transaction in ovirt-engine "it will also solve the bug of can do action checks running outside" - when not executing it from opened transaction ofcourse :-), but now it happens also by mistake. ----- Original Message ----- > From: "Liron Aravot" <laravot(a)redhat.com&gt; > To: "Michael Kublin" <mkublin(a)redhat.com&gt; > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; > Sent: Tuesday, February 12, 2013 1:06:52 PM > Subject: Re: [Engine-devel] Global transaction in ovirt-engine > > +1 > it will also solve the bug of can do action checks running outside > transaction. > > maybe we can also find a nice way to keep db only commands (without > vdsm calls) to run within transaction to avoid repeat the code to > open the transaction in such commands. > > by the way, we should solve the same for the end methods. > > ----- Original Message ----- > > From: "Michael Kublin" <mkublin(a)redhat.com&gt; > > To: "engine-devel" <engine-devel(a)ovirt.org&gt; > > Sent: Tuesday, February 12, 2013 11:38:33 AM > > Subject: [Engine-devel] Global transaction in ovirt-engine > > > > The issue is a following (I think I had raised it once), > > by default when any command is invoked in ovirt-engine a > > transaction > > is opened. > > Now, lets take a look on complicated command which is performing > > a > > lot of XML-RPC/HTTP calls and just simple update , > > such command is a main cause for the following problems: > > 1. Long transactions, each call increase a time of transaction > > 2. When transaction is opened a connection which is associated > > with > > it also in used, so a number of available DB connections reduced > > from > > connection pool. > > 3. A errors : transaction was cancelled and operation is failed > > on

> > engine side, but successes at host side. > > 4. Performance - "try to keep transactions as short as possible". > > 5. Performance - to many unneeded transactions > > 6. Bug debugging - it is very difficult to understand why > > something > > was committed and something not why transaction was reverted or > > not, > > when we have a lot of nested transactions. > > > > Now, what should be done by my opinion: > > 1. Change default behaviour - by default not to open a > > transaction > > (Today, transaction is opened and if we don't want a command > > should > > be marked > > by NonTransactiveCommandAttribute) - it is simple > > 2. The change described at 1 will require to rewrite and redesign > > some flows - more difficult, but also can be done pretty fast. > > By the way this can be or even should be done at any case. > > 3. All new commands should not be based on global transaction or > > keep > > in mind that global transaction can be disabled

> > > > Benefits, > > 1. Better performance > > 2. Cleaner code > > 3. Less bugs > > 4. Increased scale > > > > Regards Michael > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel