FrontAccounting forum — cancel_transaction (not really a bug)

Re: cancel_transaction (not really a bug)

null@example.com (apmuthu) — Fri, 16 Mar 2018 21:04:44 +0000

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)

null@example.com (joe) — Fri, 16 Mar 2018 17:42:16 +0000

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)

null@example.com (apmuthu) — Fri, 16 Mar 2018 16:08:27 +0000

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)

null@example.com (oakstreet1) — Fri, 16 Mar 2018 15:59:27 +0000

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)

null@example.com (apmuthu) — Fri, 16 Mar 2018 03:51:58 +0000

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)

null@example.com (oakstreet1) — Thu, 15 Mar 2018 21:20:13 +0000

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.