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

> > > > ----- 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 > > > > > > > need to remember that transaction also gave us 10-min limit for > > command execution, > > not saying its good or bad, but disabling the transactions will > > allow > > commands to run forever, > > this 10 min limit actually, saved us few times when commands got > > stuck in all kind of locks etc.. > > > Not exactly, if transaction has expired the JBOSS transaction > framework (Arjuna) > will not stop a running thread attached to such thread. > We can configure it in such way that a running thread will be > cancelled, but for now > it is not. So current behavior is somewhat "unexpected" - it all determines if the thread will try to use the transaction after it was "reaped off" from him. Right? If this is the case - I think this is bad. Do we have a real requirement for commands to end their execution phase at 10 minutes?