Experiment with Vertx reactive driver in hibernate-core

[beikov]

During JNation, I came up with the idea to make use of the reactive driver in hibernate-core to improve performance, by reducing the loading latency, thanks to possible network level pipelining features of the Vertx driver. In case the transaction isolation level is READ_COMMITTED and the transaction is "read only" or the persistence context is empty, we could even make use of pool level pipelining, which will essentially execute queries in parallel. Note though, that we could also try out using multiple JDBC connections for parallelizing which would be similar to pool level pipelining.

I just wanted to write down these ideas before I forget about this. Maybe we can discuss a few things here or somebody wants to work on this experiment about which we could discuss results here.

[gavinking]

It's definitely worth trying out the Vert.x driver with Hibernate ORM. I think that was a great idea.

[Sanne]

I have no objections about trying, but I'm a bit skeptical about what you're going to get out of it.

The adaptation layer isn't trivial; if the goal is performance comparison, there's a very real risk that such layer will bias your outcomes.

And also, ee need to wonder: how is that substantially different from using Hibernate Reactive?

Those pipelining capabilities are almost never going to kick in unless the model of use to invoke the driver is changed at higher level, like HR is doing.

[beikov]

And also, ee need to wonder: how is that substantially different from using Hibernate Reactive?

Well, my idea was that we might be able to merge certain parts of hibernate-reactive into hibernate-core or at least into the hibernate-orm repository if we see benefits. The API will stay the same for the user, but internally we would use a different execution model, so we would change/abstract this higher level interaction with the drivers in a way very similar to what reactive is doing (wrapping reactive driver in JDBC adapters for certain SPIs).

[gavinking]

@Sanne I think the interesting proposition is: perhaps the Vert.x driver is just faster than the legacy JDBC driver of (one or more) RDBMS just because it's newer.

I agree it's unlikely that we'll get much out of the driver being reactive per se. But if you merely view Vert.x as nothing more than an alternative driver, perhaps there's some benefit (that we'll never see without trying it).

[Sanne]

yes the fact that's new code and based on Netty for actual I/O gives it a little edge, but pgjdbc is also maintained by damn good developers... so just to set expectations I don't think we'll see enough of a difference to make such a solution worthwhile for real use (and future maintenance). Happy to be proved wrong - not meaning to say don't try it.

But the execution model is a stronger concern: remember that for the pgclient to be effective it needs to run on the io threads and never block, and you just can't easily make an adaptation layer unless we start coordinating tasks among different executor pools, and that's certainly not going to be very efficient.

[gavinking]

pgjdbc is also maintained by damn good developers

OK, but postgres isn't the only DB we're interested in. Some of the other JDBC drivers seem less well-maintained.