Managing Slick DB resources

^{Originally posted by **pjfanning** June 13, 2024}
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.