Hi, I’m the one who recently created <this PR.> I...

# exposed

[육진혁]

Hi, I’m the one who recently created this PR.

I’m trying to improve SpringTransactionManager a bit more, and I’m wondering what the Exposed maintainers think.

- The current implementation of DataSourceTransactionManager is a JDBC implementation, and it’s hard to create Exposed-specific functionality using it. To solve this, I think I should create a SpringTransactionManager that implements PlatformTransactionManager, an interface that Spring created to manage transactions, but I’m wondering why you used DataSourceTransactionManager, which is a JDBC implementation.

- If I register the SpringTransactionManager bean in a Spring container, I need to prevent the existing transaction { } and newSuspendTransaction { } from being used. (They throw exceptions, etc.) I think they don’t match the lifecycle of transactions provided by Spring and cause undocumented issues (such as returning the wrong manager in TransactionManager.current()).

If Exposed is going to continue to support Spring, it would be great if you could answer these questions so I can make improvements.

[육진혁]

Even if we give up backwards compatibility, I think the user experience will be better if we align with Spring’s lifecycle.

In fact, ktorm prevents you from using its proprietary transaction management technology if you register the TransactionManager as bean.

[Chantal Loncle]

@육진혁 Thanks very much for getting back to us so soon with this.
Would you be willing to open a ticket on YouTrack so that we can better track responses to this discussion over time?

[육진혁]

Thanks! I open ticket about this issue on YouTrack
(I didn’t realize use YouTrack)