Quote Originally Posted by Samuel Pizarro View Post

explicit Being/End Transactions always LOCK all tables opened in normal mode (IE not in read-only mode).

This is like this.... since... FOREVER.

The difference when using an SQL backend, is the lock size.. table level or row level. SQLs normally does row-level locking.

Even if df performs a LOCK <table> command, the row will only be locked if there is any active record in the global buffer.
So, I would start looking at that.. what tables were inactive on 19.0 that now have an active row in their buffer in 19.1.

If you don't want other tables that does not belong to the scope of your transaction to be locked,, it's your responsibility to change the open mode for them to read-only, before the Start_transaction block.
And after the transaction is done, revert the open mode back to normal.
This is exactly what DD class does internally.
thanks Samuel, perhaps some code playing with my sessions table may cause the locks, any tip in how can i watch my buffer while my debug is active? i mean, i'm thinking in set a breakpoint inside the transaction, then run my application, when the debug achieve the breakpoint i check all the active table, do you think it make sense? thanks again.