FrontAccounting forum — cancel_transaction (not really a bug)

Re: cancel_transaction (not really a bug)

2018-03-16T21:04:44Z

I think it is for puritanism only. The reset should be sufficient for now. If any third-party careless code called it, possibly it might go into negative.

Re: cancel_transaction (not really a bug)

2018-03-16T17:42:16Z

I have never heard of any problems here before. Please be a little more specific. If this is an error the test is very hard to setup, so please be sure that you have observed a problem.

Joe

Re: cancel_transaction (not really a bug)

2018-03-16T16:08:27Z

The cancel_transaction() resets the value of the $transaction_level to 0 whenever a script is called in FA, and it happens when the DB connection is setup each time in includes/db/connect_db_mysqli.inc.

@joe: any fixes here?

Re: cancel_transaction (not really a bug)

2018-03-16T15:59:27Z

Yes, I was referring to sql_functions.inc. The commit_transaction() could cause the transaction level to go negative, which would nullify all following transactions. I was just thinking that commit transaction should test transaction level for > 0 before decrementing the value.

Re: cancel_transaction (not really a bug)

2018-03-16T03:51:58Z

There are no BEGIN ... COMMIT raw blocks in FA core codebase and possibly not even in any official Extension.

However, local SQL wrapper functions begin_transaction() and commit_transaction() exist and have such a check for non negative values as defined in includes/db/sql_functions.inc.

cancel_transaction (not really a bug)

2018-03-15T21:20:13Z

I'm just familiarizing myself with the code before I get started on a rather major extension ...

In /includes/db/sql_functions.inc, there is a function called "cancel_transaction". I'm not sure if or when that is called, but if it were called inside of nested calls to begin/commit transaction calls and any function called "commit", the global $transaction_level would go to -1, which would cause all following begin/commit calls to be ignored.

I could be missing something, and maybe the cancel is never called, but I can imagine some additional checks to be sure that $transaction_level never goes negative. I'm not here to criticize something I don't completely understand. I just thought someone might want to consider this as a source of some unpredictable behavior, as, once the global was out of range, all subsequent "transactions" would actually not be done as transactions.