Is this library Vertx 3 compatible ?

[javajack]

Vertx 3 is already having some data access libraries

http://vertx.io/docs/vertx-sql-common/java/
and
http://vertx.io/docs/vertx-jdbc-client/java/

But I want to leverage this API as it is more intuitive in nature.

Can we use this library with Vertx 3 for asynchronous processing ?

[davidmoten]

Hi, I'm not familiar with Vertx 3 so you're on your own here (unless a subscriber to this list knows the product).

[zsiegel]

@javajack Yes you can. Just be sure to schedule the work with the RxHelpers class in the vert-rx package

[zsiegel]

@javajack a quick example might look something like this...

db.select().autoMap(User.class)
     .subscribeOn(RxHelper.blockingScheduler(vertx))
     .observerOn(RxHelper.scheduler(vertx))
     .subscribe()

@davidmoten I am a fairly new user of this library but my understanding would be that the library is respecting the thread preference by saying subscribeOn and observeOn. In my quick testing this seems to be the case.

[vietj]

it would be great to have this library to work well with Vert.x

perhaps we can collaborate on integration test with Vert.x 3.x and documentation ?

[davidmoten]

@zsiegel yep that's right, normal manipulations with observables are fine as long as some sort of mapping of the ResultSet to an object occurred synchronously. The library leads you that way anyway with the method chaining. You have to do something like this to get into trouble with threads:

db.select()
    .get(rs -> rs) 
    .observeOn(Schedulers.io())
    .map(rs -> rs.getString(1))
    .toList().toBlocking().single();

In the above statement the resultset is mapped to an object on a different thread than the thread on which the resultset was created. Jdbc drivers don't guarantee thread safety in this scenario. As long as you avoid this sort of usage you can do whatever you like to your observables.

[davidmoten]

and thanks for answering this one @zsiegel !

[kdurnoga]

Is setting schedulers with observeOn/subscribeOn needed when using rxjava2-jdbc with non-blocking connections?

[zsiegel]

@kdurnoga you should always use the .subscribeOn to ensure you are getting the proper threading behavior. RxJava runs on the current thread by default

[davidmoten]

Best to ask rxjava2-jdbc questions on it's project. Default behaviour in rxjava2-jdbc is to run on the io() scheduler because of the non-blocking connection pool. If you have explicit requirements about what thread gets the results use observeOn.