Discussion: Session + Concurrency

The javadoc for Session explicitly states that:

“Multiple sessions should be used when working with concurrency; session implementations are not thread safe.” “At most one transaction may exist in a session at any point in time. To maintain multiple concurrent transactions, use multiple concurrent sessions.”

Thus, in a context of a web application, it seems the best would be to have a pool of opened Sessions which map one to one with a thread pool (ExecutionContext) of the same size.

Also, it seems to me that this is something the library should provide out of the box. But it is still not clear to me how this should work. I am only sure the underlying EC should be supplied by the user.

[BalmungSan]

After thinking a while about this and after carefully reading this I believe the best idea would be what Gabriel suggested in the first place, having some kind of semaphore that ensure each Session instance can only be used from a thread a the time. This will guarantee thread safety. geoffjohn11 proposal of hiding the Session also ensured thread safety, however creating and destroying sessions every time a query was made was costly and removed an important property of the system of being casually consistent.

If some downstream user wants to execute queries in parallel, then it would be his/her responsibility to instantiate many Sessions and load balance all the petitions between them.

---

I would try to implement this in the weekend. So if anyone has a different opinion and want to discuss it, please let me know during the week.

[geoffjohn11]

@BalmungSan I created an example of sharing a neotypes Session across threads (which is easiest to do using the Scala Future effect type). Since there already was an example project using Akka http and futures in the examples repo, I used that instead of the http4s and IO file you gave me, just so I could get something going as quickly as possible.
My test repo is located here: https://github.com/geoffjohn11/sessionShare

Uncomment the duplicated line in “dangerMethod” to execute the “incrementMovieYear” method in different threads (executing in separate Scala Futures). This results in a neo4j session exception:

org.neo4j.driver.internal.NetworkSession.lambda$ensureNoOpenTx$35(NetworkSession.java:526)

'You cannot begin a transaction on a session with an open transaction; either run from within the transaction or use a different session.'

It looks to me that because reads and writes both open a transaction with beginTransactionAsync, and at most one transaction may exist in a session at any point in time (in the neo4j session doc), the action fails. The second thread can’t use the shared session because they both open a transaction.