mysql-native v2.1.0

[Nick Sabalausky (Abscissa)]

On 03/08/2018 06:57 AM, bauss wrote:
> 
> But if you can't store the pools anywhere, how are you supposed to use 
> them with vibe.d?

You can store the pools wherever you need to, just don't hold onto a 
Connection past the end of a vibe task.

> Creating a new pool for every thread seems expensive and dosn't that 
> defeat the purpose of using pools in the first place?
> 
> I mean a 1000 people could connect to a website and potentially that 
> could create a thousand threads (It probably won't, BUT it could.) and 
> thus it can't be afforded to create a pool per request.

This is more a question for vibe's Sonke, to be honest.

What I do know is that vibe's basic task distribution typically involves 
one task/request per *fiber*, not per thread. And that vibe is based 
heavily around handling multiple simultaneous requests/tasks/fibers 
within a single thread.

Beyond that, I have no idea how vibe deals with threads, hence my 
suggestion that if you're having trouble, it might be worth seeing 
whether going totally thread-local with everything might help. Just a 
thought. At the very last it might help narrow it down.


> I mean it's kind of a corner case, but it's a common corner case for big 
> applications.
> 
> I don't create any explicit threads.
> 
> But like I said, it seems to work after I stopped returning the 
> connection and just the pool.
> 
> so I think the problem wasn't the pool, but the connection itself.
> 
> At least I can't reproduce it and tried with hundreds of queries at once 
> and before I could reproduce with less than 10.
> 

I admit I'm unclear at this point which problem you're referring to, and 
whether or not you're saying it's fixed now. (Pardon my confusion - been 
a long day.)

If you mean issue #153, then I wonder if that might be the same cause as 
#170 (Same symptoms at least: "Acquiring waiter that is already in use"):

#170: https://github.com/mysql-d/mysql-native/issues/170

Sonke figured out just a few hours ago, and I confirmed, that #170 is 
caused by a bug in MySQLPool.lockConnection introduced in v2.1.0. I plan 
to have that fixed with a new release today.

That bug turned out to be caused by MySQLPool.lockConnection allowing 
the LockedConnection!Connection it received from vibe to degrade down to 
a plain Connection (because of alias this allowing implicit conversion). 
So MySQLPool.lockConnection would then return the *raw* Connection 
instead, thus allowing LockedConnection to go out of scope and reclaim 
the connection as soon as MySQLPool.lockConnection returned.

Sonke's been putting thought into how to adjust vibe's LockedConnection 
so this can't happen by accident. Maybe your lib fell prey to the same 
accident mine did?


> And yes I need support for multiple connection strings. It's not an 
> application, it's a library for writing enterprise websites/webapis and 
> thus it should be scalable, since most enterprise solutions uses 
> multiple databases.

Ah, I see. Fair enough.