Gavin King

Oh, geez, my apologies @aguibert, I just realized that this problem isn't related to batching at all. It's something to do with `BigDecimal`. I should have looked more closely at...

@aguibert I was able to re-enable the test after making this change: Apparently the driver chokes on certain numerical values of the `BigDecimal`.

> the stacktrace in the OP is what you get when you try to store this certain BigDecimal value? Yup.

@vietj you could look at how HR does it for inspiration: essentially, we store the connection in the vert.x local context from the outermost call to `withTransaction()`, and pull it...

> @technical-debt-collector so something like `getOrCreateContext()` but with a connection But I would make it accept a function reference.

> do you mean like with Pool.withTransaction() where the transaction is committed/rolled back and the connection is released after the function execution? Right. This was we can guarantee that things...

I mean, that works, but I sorta hate Boolean parameters. In this case my preference would be to have a new method.

The API described above is not really what I was thinking of, and it doesn't seem to me to be as easy to use as what we have in Hibernate...

So instead of calling `getCurrentConnection()` you just call `withTransaction()` again, and get passed everything you need (here it would be the connection and transaction objects created by the surrounding call...

> locally bind the transaction to the current vertx context (and fail if there is already a transaction) To be clear, I think this is where our ideas diverge. You're...