GitHub user pjfanning edited a discussion: Managing Slick DB resources
When you call [databaseConfig.db](https://github.com/slick/slick/blob/b878d45556fb6b4799e62a5d3c08364def51a89f/slick/src/main/scala/slick/basic/DatabaseConfig.scala#L15-L18), you are expected to close that db instance. pekko-projection-slick has never bothered to do this. It appears that pekko-projection-slick users create their own databaseConfig and it is left to them (at the moment) to know about and implement the `databaseConfig.db.close()` call. Have a look at [SlickProjectionSpec](https://github.com/apache/pekko-projection/blob/bb4e88a18d425c2ff66449fc323a87f36217f21b/slick/src/test/scala/org/apache/pekko/projection/slick/SlickProjectionSpec.scala) to see how this test spec creates a databaseConfig and then in `afterAll` it calls `databaseConfig.db.close()` If we were to take responsibility for closing the databaseConfig.db instances, there are some problems: * there is no lifecycle that we can rely on, we are probably left with adding a shutdown hook or something like that * There are a lot of functions in [SlickProjection](https://github.com/apache/pekko-projection/blob/bb4e88a18d425c2ff66449fc323a87f36217f21b/slick/src/main/scala/org/apache/pekko/projection/slick/SlickProjection.scala) that call `createOffsetStore` and this `createOffsetStore` calls `databaseConfig.db` - potentially create a new db instance that needs managing. If you call `databaseConfig.db` more than once on the same databaseConfig instance, you should get the same db instance (they are lazily created and reused). This is my opinion - I think we should not change anything and just document that users need to look after their own databaseConfig lifecycle. GitHub link: https://github.com/apache/pekko-projection/discussions/168 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
