apache / pekko-projection

Apache Pekko Projections is intended for building systems with the CQRS pattern, and facilitate in event-based service-to-service communication.
https://pekko.apache.org/
Apache License 2.0
17 stars 8 forks source link

Managing Slick DB resources #172

Open pjfanning opened 3 months ago

pjfanning commented 3 months ago

Discussed in https://github.com/apache/pekko-projection/discussions/168

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.