Slick 3 and execution contexts

[Matan Safriel]

Hi,

From an initial review of the source code I believe slick always uses the default scala execution context, am I correct in that?

If so, what can be said about the relation to the thread management employed by the underlying HikariCP connection pooling? I am not a Java expert and not sure how HikariCP manages threads.

Also, in Play framework, there is a default play-specific thread pool which is according to the documentation an Akka dispatcher, and recommended for most application code purposes. I wonder if you have any rule of thumb for choosing between the two (unless, one automatically maps to the other), for slick. Maybe I missed something in the configuration options, in that case apologies. I have already integrated slick into play (without needing the play slick plugin which doesn't support slick 3.0.0-RC1 for now, I think; wasn't that hard). 

Thanks,

Matan

[Stefan Zeiger]

On 2015-03-14 16:43, Matan Safriel wrote:

From an initial review of the source code I believe slick always uses the default scala execution context, am I correct in that?

No, Slick never uses that, except in the no-args constructors of DistributedDriver and MemoryDriver, which exist for backwards compatibility and are deprecated.

If so, what can be said about the relation to the thread management employed by the underlying HikariCP connection pooling? I am not a Java expert and not sure how HikariCP manages threads.

A connection pool manages connections, not threads. HikariCP uses some auxiliary threads for its internal cleanup tasks but once you get a connection from the pool, you use it directly on whatever thread you want.

Also, in Play framework, there is a default play-specific thread pool which is according to the documentation an Akka dispatcher, and recommended for most application code purposes. I wonder if you have any rule of thumb for choosing between the two (unless, one automatically maps to the other), for slick. Maybe I missed something in the configuration options, in that case apologies.

Combinators like DBIOActions#flatMap, which have to execute user code, take an implicit ExecutionContext. This is the place where you should use one provided by a framework like Play instead of ExecutionContext.global.

I have already integrated slick into play (without needing the play slick plugin which doesn't support slick 3.0.0-RC1 for now, I think; wasn't that hard).

The plugin is being updated for 3.0. It will do less than before because Slick now has its own configuration syntax and provides asynchronous execution by itself.

--
Stefan Zeiger
Slick Tech Lead
Typesafe - Build Reactive Apps!
Twitter: @StefanZeiger

[Matan Safriel]

Thanks for the clarification, and by the way, I think the HikariCP wiki provides a good guide for concurrency tunning at https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing if it helps anyone.

--

---
You received this message because you are subscribed to a topic in the Google Groups "Slick / ScalaQuery" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalaquery/qOhSx5oQ9MU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalaquery+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalaquery/5504F5DE.5090602%40typesafe.com.

For more options, visit https://groups.google.com/d/optout.

[Rahul Gulabani]

Hello,

I also have similar confusion. Slick 3.x uses own connection or thread pool as per document.
So why do we need to provide execution context separately.
Am I getting confused between execution context and threadpool.
I am sure slick 3.x uses own connection and thread pool .

Br/
Rahul