Hello Oren, Not sure what you're looking for in particular. Everything seems to be there:
"asynchronous" transactions: http://www.jooq.org/javadoc/latest/org/jooq/DSLContext.html#transactionAsync-org.jooq.TransactionalRunnable- "asynchronous" execution: http://www.jooq.org/javadoc/latest/org/jooq/DSLContext.html#fetchAsync-java.util.concurrent.Executor-org.jooq.ResultQuery- These are just some example APIs. Are you looking for something particular? Cheers Lukas 2016-11-23 20:35 GMT+01:00 <[email protected]>: > Hi, > > Looking for an async way to work with mariadb I came across jooq and this > thread, but also across this blog post: https://blog.jooq.org/2014/ > 09/23/asynchronous-sql-execution-with-jooq-and-java-8s-completablefuture/, and > I found them contradicting - the older blog describes a working solution > while from this recent thread it seems that the solution is not yet exist. > What am I missing? > > Thanks, > Oren > > On Friday, May 27, 2016 at 10:00:18 AM UTC+3, Lukas Eder wrote: >> >> Thanks, Samir >> >> >> 2016-05-26 23:35 GMT+02:00 Samir Faci <[email protected]>: >> >>> I also have a use case where I need to inject some additional SQL to be >>> executed within the same transaction. >>> >> >> Would you mind elaborating your use-case a little bit? >> >> >>> the code snippet you describe would sound ideal for us. >>> >>> >>> ctx.beginTransactionAsync() >>> .thenApply(... -> ...) >>> .thenApply(... -> ...) >>> .thenApply(... -> commit()); >>> >>> >> So far, this was just a very high level sketch. Let's assume we'd be >> going this way. There would be two new alternative transaction APIs: A >> blocking one and a non-blocking one. The blocking one might look just like >> JDBC or JTA: >> >> Transaction transaction = ctx.beginTransaction(); >> ctx.insert()... >> ctx.update()... >> >> Savepoint savepoint = transaction.savepoint(); >> >> ctx.delete()... >> transaction.commit(); >> >> >> The non-blocking one would need to maintain the transaction state >> throughout the .thenApply() call chain, exposing it in case someone >> wants to nest stuff (using savepoints) or commit/rollback early. >> >> The difficulty of this is that CompletionStage is not designed for this >> use-case. It is designed for passing only computation results to the next >> computation, not (transaction) contexts. This means that the context needs >> to stay external or implicit, which also violates the CompletionStage >> design. >> >> One option would be to subtype the JDK's CompletionStage and make that a >> TransactionalCompletionStage. So, more specifically than what I've stated >> earlier: >> >> ctx.beginTransactionAsync() >> .thenApply(transaction -> transaction.ctx().insert()) >> .thenApply(transaction -> transaction.ctx().update()) >> .thenApply(transaction -> transaction.savepoint()) >> .thenApply(transaction -> transaction.ctx().delete()) >> .thenApply(transaction -> commit()); >> >> >> Where "transaction" would be that TransactionalCompletionStage<T>, where >> <T> is the outcome of the previous computation (Integer in case of >> insert/update/delete, Result in case of fetch, Void in case of savepoint). >> >> I'm a bit wary of implementing that, though. There hasn't been a lot of >> literature around, documenting such things (as with subtyping the >> Collections API). >> I'm very open to hear your thoughts on this matter. >> >> Best >> Lukas >> > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
