pjfanning opened a new issue, #172:
URL: https://github.com/apache/pekko-projection/issues/172

   ### Discussed in https://github.com/apache/pekko-projection/discussions/168
   
   <div type='discussions-op-text'>
   
   <sup>Originally posted by **pjfanning** June 13, 2024</sup>
   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. </div>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to