uvalib/tracksys

Problem with invoice creation (Mysql2::Error -- deadlock on transactions)

cmm2t opened this issue · 2 comments

Several orders over the past months have completed to the point that they could be delivered to patrons, but when they were delivered, the invoice was not created. Error messages sometimes show this as a Mysql deadlock error, but not always. Three examples of orders this happened to are: 7014, 7016, 7018. The PDFs are not being saved in the database, and the order files are not being moved to ready_to_delete.

This is a transient issue, and very hard to test. However, the addition of some exception handling in processors or libraries that make transactions on a class should help. Here's a first pass, yet to be committed, on the ImportIviewXml method that builds MasterFiles:

I created a gist showing this technique which may be copied into other classes/modules as needed.

Lucky for me, I was trying a few large batches when I wrote this, and have had four or five good tests of this code. What we now get are messages in the main Rails log file, not failures reported to AutomationMessages.

I anticipate that keeping your hands off the mouse for the ~15 minutes or so this will take to run will improve performance, as extra pages requests mean more potential locks on tables.

Okay, so what you mean is that I need to be patient and let things finish? That may take a personality transplant, but I'll see what I can do . . . .

Thanks! I hope you and your bunnies are enjoying the snow. I've had enough myself, but I did get some cleaning done today.

Christina

On Mar 17, 2014, at 2:18 PM, "Matthew Stephens" <notifications@github.commailto:notifications@github.com> wrote:

This is a transient issue, and very hard to test. However, the addition of some exception handling in processors or libraries that make transactions on a class should help. Here's a first pass, yet to be committed, on the ImportIviewXml method that builds MasterFiles:

I created a gist showing this technique https://gist.github.com/MatthewStephens/0eea96f5f3bff274ae9d

Lucky for me, I was trying a few large batches when I wrote this, and have had four or five good tests of this code. What we now get are messages in the main Rails log file, not failures reported to AutomationMessages.

I anticipate that keeping your hands off the mouse for the ~15 minutes or so this will take to run will improve performance, as extra pages requests mean more potential locks on tables.


Reply to this email directly or view it on GitHubhttps://github.com//issues/151#issuecomment-37851115.