Resource icon

Deadlock Avoidance by Xon 1.0.21

No permission to download

Xon

Well-known member
Xon submitted a new resource:

Deadlock Avoidance - Workarounds for sporadic deadlocks on busy forums

XenForo's Datawriters have a _postSaveAfterTransaction() method. This method is intended to run after a database transaction is finished, but if a DataWriter is called from with-in another DataWriter, this does not happen.

This incurs the risk that various notification actions will pull in large queries into the transaction, which increasing the risk of deadlocks on a busy forum.

This is a formally private add-on which has been in use for about a month before being released.

This add-on is only for busy forums which sometimes experience deadlocks on the listed...

Read more about this resource...
 
Actually, it throws a number of errors conflicting with the tapatalk addon.

Parse error: syntax error, unexpected T_STRING, expecting T_CATCH in /home/xxx/library/SV/DeadlockAvoidance/XenForo/DataWriter/ReportComment.php on line 12
 
Last edited:
@TheComputerGuy sorry, but I don't think this add-on will work for you.

Actually, it throws a number of errors conflicting with the tapatalk addon.
Not that surprising, but there is little I can do to fix that as I don't have tapatalk installed.

Parse error: syntax error, unexpected T_STRING, expecting T_CATCH in /home/xxx/library/SV/DeadlockAvoidance/XenForo/DataWriter/ReportComment.php on line 12
This add-on requires php 5.5, not php 5.4, I'll update the add-on description to correctly state that.
 
@TheComputerGuy sorry, but I don't think this add-on will work for you.


Not that surprising, but there is little I can do to fix that as I don't have tapatalk installed.


This add-on requires php 5.5, not php 5.4, I'll update the add-on description to correctly state that.
Makes sense! thanks for the quick reply...We are upgrading to php 5.6+ soon....but the tapatalk...well its sticking around.

Thanks!
 
We use galera for multi master replication. The add-on does not work always, we got this error even with it installed:

Code:
Zend_Db_Statement_Mysqli_Exception: Mysqli statement execute error : Deadlock found when trying to get lock; try restarting transaction - library/Zend/Db/Statement/Mysqli.php:214
Generated By: Unknown Account, Today at 1:31 AM
Stack Trace
#0 /var/www/*****/library/Zend/Db/Statement.php(297): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /var/www/*****/library/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#2 /var/www/*****/library/XenForo/Model/Thread.php(2422): Zend_Db_Adapter_Abstract->query('\n\t\t\tINSERT  INT...', 571128)
#3 /var/www/*****/library/XenForo/ControllerPublic/Thread.php(159): XenForo_Model_Thread->logThreadView(571128)
#4 /var/www/*****/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#5 /var/www/*****/index.php(13): XenForo_FrontController->run()
#6 {main}
Request State
array(3) {
  ["url"] => string(62) "http://*****/threads/threadtitle.571128/"
  ["_GET"] => array(1) {
    ["/threads/threadtitle_571128/"] => string(0) ""
  }
  ["_POST"] => array(0) {
  }
}
 
@HWS That is really weird, I'm not sure how the hell you can get a deadlock from a single-statement insert on a code path with no explicit transactions for a table never touched by the thread or post DataWriters.

Especially when this add-on isn't even active in that code-path, or any other code paths related to xf_thread_view table!
 
Weird for us too. Must have something to do with the Galera setup. We hoped it will be solved with your add-on. Unfortunately it isn't. Would help if XF automatically retries transactions out of the box.
 
This add-on wasn't designed to target that sort of deadlock, but to target what is basically a design flaw in DataWriters. There are a few other sites patched, which are called inside a DataWriter transaction which shouldn't be.

Weird for us too. Must have something to do with the Galera setup. We hoped it will be solved with your add-on. Unfortunately it isn't. Would help if XF automatically retries transactions out of the box.
Hmm, I think what you are seeing is the fact that updateThreadViews and logThreadView interact poorly with Galera. Especially if the xf_thread_view tables is the default table types.

One of my other add-ons (Redis View Counters) uses Redis to store view counters logs until they can be persisted to the database as very simple update statements, without the update/join/truncate hoops. But this does require switching over from Memcache to Redis as your caching layer.

And I don't think how that Redis View Counter add-on uses Redis will work with a Redis cluster, which is a long term plan to fix.
 
Last edited:
We converted all *_view tables from memory to innodb, since this is Galera'a only supported table type.

I'll try your Redis add-on.
 
  • Like
Reactions: Xon
Question:
What's a large forum?
So if we have 100 online trying to post 'something' at the same time or we have 1000 doing the same.
Won't we hit these deadlocks either way? and would it hurt to install this addon on a not large forum?
 
Question:
What's a large forum?
So if we have 100 online trying to post 'something' at the same time or we have 1000 doing the same.
Won't we hit these deadlocks either way? and would it hurt to install this addon on a not large forum?
I've developed these features for forums which peak at 2000-3000 users online within 15 minutes, and as they grow I'll update this add-on to keep it scaling.

This add-on also introduces shortcuts; such as remove the list of online members which I feel are useless when you have that many online.

Installing this add-on wouldn't hurt, but at the same time it introduces non-standard behaviour which may surprise you.
 
How would we see if deadlocks are happening to us like this?

Our forum falls into the "busy" category so it sounds like we might benefit from this but we also have a pretty powerful server so not sure...
 
Top Bottom