I guess you're right. My goal was to see how rodauth-oauth acts under concurrency, but I might have gone beyond what I wanted to test.
I ended up disabling parallel testing for jdbc sqlite due to what I found here: https://stackoverflow.com/questions/10707434/sqlite-in-a-multithreaded-java-application . Thanks again for the support, Tiago A domingo, 30 de agosto de 2020 à(s) 18:58:36 UTC+1, Jeremy Evans escreveu: > On Sunday, August 30, 2020 at 8:45:06 AM UTC-7, Tiago Cardoso wrote: >> >> > Are you using a connection string of "jdbc:sqlite::memory"? >> >> In the link I sent you, I used "jdbc:sqlite:/$(pwd)/test.db. The error is >> related with some file lock, which probably means that access to the file >> db in sqlite is assumed not to be concurrent(?) and running tests in >> parallel can't possibly go? >> >> > You could try limiting the ActiveRecord and Sequel connection pool >> sizes to 1 >> >> I'll try that, thanks for the suggestion. >> >> > Unless it is critical, I would recommend not testing in parallel mode >> when using SQLite,... >> >> That's definitely on the table. However, concurrent tests don't break >> with CRuby, hence why I thought something was wronng with the jruby build. >> Maybe the c-extension is somehow limitng the pool? >> > > Maybe. It seems unlikely anyone is using JRuby/SQLite/rodauth-oath in > production, which is why just making the tests single threaded seems > easiest. If you are on JRuby/JDBC, a database written in Java such as > H2/HSQLDB/Derby is probably a better idea than SQLite if you did want a > file-based database. > > Thanks, > Jeremy > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/62694125-a7fb-4c7a-a251-773d3e4e1321n%40googlegroups.com.
