Question about hibernate reactive release schedule

[semistone]

Hi,
Our team is trying to build hibernate in the reactive application.
We have checked hibernate-reactive and seem nice to use.
but we also notice that it still in alpha release.

Does anyone have a rough idea of when will have a 1.0.0 release?

Thanks

[emmanuelbernard]

Not precisely at this stage. But I can explain our thinking.
Right now we are doing performance testing to validate that we can reach interesting scalability models (better than Hibernate blocking). That will validate our work.
Then we will have a relatively long period of feedback on the API (what’s missing, what should be improved etc). As this is new territory for a lot of people.
If you already have feedback, I’d love for you to send an email to the hibernate-dev mailing list. The team will appreciate it a lot.

[emmanuelbernard]

Cc @gavinking

[emmanuelbernard]

Cc @Sanne

[emmanuelbernard]

Come to think of it, you can put your feedback here. Let me reopen it :)

[avillev]

Hello @emmanuelbernard
I am with @semistone , we are testing the lib and it looks quite good.

I guess the main thing which disturbs us is the non-support of the @Version annotation for the optimistic lock management and ... the fact that is not released yet :)

[Sanne]

Welcome @avillev and @semistone :)

I saw your forum questions as well, sorry for the delay.

I guess the main thing which disturbs us is the non-support of the @Version annotation for the optimistic lock management ...

I'll assume that's #201 ? I think we can handle the internal changes needed to support it, but it would be really helpful to get your input to define the API and semantics.

Regarding release timelines: we've been releasing many Alpha releases recently on an "as needed" base for our own testing and integration needs. But things are looking good now and I suppose we could switch to regular Beta releases, and work on a proper project announcement.

So you can already find e.g. org.hibernate.reactive:hibernate-reactive-core:1.0.0.Alpha6 on both JCenter and Maven Central; I assume you're asking for a "Final" stable release?

To make it a "final" release I'd hope to have more user feedback; TBH this is the first time someone not from our immediate team seems to have tried it out - which is great as we hadn't announced the project yet!

Some ballpark estimates:

You might have noticed the project development slowed down a bit; the reason is we're focusing on benchmarking and load testing to verify some aspects. Website preparation and proper documentation will take a little time as well.
I expect after that - so in a couple of weeks? - we'll be able to announce the project and then we might need ~2 to ~3 more months of community feedback and API polishing to make it final.

[gavinking]

Hi @avillev, I think you’ve misinterpreted #201. The @Version annotation and optimistic locking in general works perfectly well as far as I know. What’s described in #201 is something very specific: a feature of JPA 2.0 that I’ve never used myself and I doubt many people use.

[semistone]

Thanks for your reply.

let me share our testing result of comparing different SQL client libs

1000 QPS with spring webflux
simple select query return 3 records only
connection pool: 16

	r2dbc	r2dbc+spring	vert.x	hibernate rx + vertx	hikari + jdbc	hibernate old + hikari + jdbc
mean(ms)	6	10	4	2	2	5
99th pct(ms)	59	75	8	5	21	72
95th pct (ms)	39	56	6	3	3	7
75th pct(ms)	3	3	4	3	2	2
50th pct(ms)	2	2	3	2	2	2
cpu system	7.8	12	8	7	6.7	14
cpu process	3.6	3.6	3	2.8	3.1	4
thread numbers	114	132	83	75	103	150

in 1000 QPS, active connection about 13 (R2DBC metrics)

in 3000 QPS, all failed due to connection pool size.

[avillev]

@gavinking
Good to know for the optimistic lock. That is great news.

Thanks to @semistone 's table up there you can see that the rx hibernate api is faster than the other alternatives.

At that point, I think the only limitation we have is ... that it is an alpha :).
At least the JPA part of the interfaces would not change (annotations and stuff). But I guess the main concern would be stability. Of course if we choose to use it, we'll probably have a lot of feedback to do.

[Sanne]

Nice data, thanks a lot for sharing. That looks indeed encouraging; now of course that might change as we stabilize, but I suspect it might improve as we've been analysing our results and identified some issues, such as the fact that we're using a sub-optimal connection pool.

We didn't share our benchmarks yet as it's usually a bit tricky to get people to not take those numbers too seriously, when we're still making many changes - but I look forward to share it all soon. FWIW, we're focusing on "fully reactive systems" end-to-end: it should make the benefits more visible when you have both a web technology modelled using a fully reactive engine, all the way to the DB. You'll soon be able to see one such example in the Quarkus quickstarts repository - it's not there yet but it will be in a few days.

Regarding "stability" : I suppose you mean API, such as us stopping to move packages? Stuff is certainly getting more stable now.

[avillev]

Thx @Sanne
We decided to give it a go for the next months. We are using it in a Reactive Spring webflux application.

Worst case scenario we could roll back to a blocking hibernate if everything fails :).

But anyway, you can expect some news from us in the future.

I guess we could close that issue ?

[Sanne]

Great, thanks @avillev