On Saturday, December 19, 2015 at 12:28:41 AM UTC-6, Jeremy Evans wrote:
>
> On Friday, December 18, 2015 at 6:25:22 PM UTC-8, Mike Pastore wrote:
>>
>> Is there a simple way to make the proc thread-safe or is there another 
>> strategy I can employ? Or am I being overly cautious? :-) 
>>
>>  If you are really concerned about it, you can always use a mutex inside 
> the proc.  But I wouldn't worry about it.  The proc is only called when a 
> new connection is needed, which should be infrequent in most production 
> applications as the connections are cached.  The worst case scenario is 
> that two threads would connect to the same backend, but assuming the number 
> of simultaneous connections you are allowing is greater than the number of 
> read only-slaves (true in most cases), that's going to be be true anyway.
>

Ah, excellent. Thanks Jeremy. I'm assuming that all works out because 
FixNums are immutable. That puts my mind at ease!

On a somewhat-related topic, I've noticed that after I bounce the MySQL 
(MariaDB) server, requests start failing with:

2015-12-19 06:18:32 - Sequel::DatabaseDisconnectError - Mysql2::Error: 
MySQL server has gone away:


Even though MySQL is back online and ready to receive queries. I have to 
restart Puma to get the workers to reinitialize their connections. Is there 
a way to make the Sequel connection pool a little more robust so it handles 
this situation better?

Thank you again,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Reply via email to