Obtain JDBC connection

Akka Libraries Persistence / Event Sourcing
1

Hi All,

(Sorry if this is a FAQ).

I’m successfully using Java with MySQL for persisting my events. I would like to access to the DB connection to perform ancillary actions on the DB. I’m using the akka-persistence-jdbc. How can I perform inserts/query
reusing the already existing Slick connection? The JdbcReadJournal does not have any access to that.

Thanks!

2

Hi @mascanc,

And how are you using the plugin? In which kind of application? Is it a Play or Lagom application?

I’m asking it because both Play and Lagom has its own way to expose the JDBC connection to JPA and it’s preferable if you use those APIs instead of hooking into the plugin.

3

Hi @octonato,

I’m using Java, with akka-persistence and akka-persistence-query, and the application is a normal CQRS application. The functional constraint that I’ve is basically to persist in the read database the event in the same
message.

I’m not using Lagom nor Play.

4

Yeah, I see.
Lagom has this built-in.
If you can’t move to Lagom, then maybe you should try get some inspirations from there.

Have a look at JpaSession and the read-side processors for JPA.

Note that Lagom goes much further than that. It also helps you to shard your journal and have different consumers polling data from it distributed in your cluster.

5

Just for clarification, do you mean that you want your read-side model to be persisted on the same transaction as the events emitted by your write-side? Are you trying to achieve strict consistency over write and read-side?

Or do you mean, when consuming the events you want to track its offset on the same transaction as your read-model?

6

Renato, basically I’ve been asked to make this particular event available in the read part of the CQRS before the actor respond to its sender.

7

This is not very much aligned with the current plugin architecture. The akka-persistence plugin architecture is conceived to allow append only inserts with asynchronous propagation to the query side. You want strict consistency around write and read side.

It’s also so that you can’t have access to plugin infrastructure components from inside the actor. The PersistentActor must stay agnostic of the underlying plugin implementation. That’s actually what allows us to have different plugin implementation for completely different database technologies.

However, you can try to customize the JDBC plugin for your needs.
The JDBC has a DAO layer sitting between the plugin API and Slick. You can implement your own DAO variant that takes the events, processes it like you would do when consuming the events on the query side and let them be save all together with your view model on the same transaction.

Note that you won’t be able to run JPA code in there. You will need to use Scala, Slick and probably some raw SQL, so I’m not so sure if that will fit your needs.