That's a great point, the only issue with the request-scoped connections/transactions is that if your requests have blocking code, your connection will remain open until the blocking completes.
I just experimented with some logging statements in our code and confirmed that even though we use non-blocking calls to web services, the database connection still doesn't get released until after all the calls in the controller have been completed. As an example, we use promises to make web service calls (i.e. WS.url().get()), but we just pass the promise response up the chain until the controller itself says "Once this promise redeems or fails, I'll return." And since that depends on the web service call completing, our connection sits idle while this is happening. Can you clarify what you mean by a "pre-action"? Do you just mean that you add the @With(TransactionHandler.class) annotation, and the "pre-action" refers to TransactionHandler.class? In our app, we just wrap all request calls in the Global.onRequest(). Also, I realize much of this discussion is specific to Play Framework, but hopefully it's instructive for anyone trying to decide on how to scope their connections. Josh On Thursday, September 4, 2014 7:19:22 AM UTC-7, Stéphane Cl wrote: > > Hello, > I use pre-actions for getting a database connection from the pool, > starting and committing transactions. > Then I just decorate my controller methods with something like > @With(TransactionHandler.class) wherever I need a database transaction. In > my pre-.action I can catch exceptions, rollback or commit without any issue. > > If you are doing some background processing, it's ok as long as your pool > doesn't run out of connections. If you have dozens of long running tasks, > each having it's own Connection but not using it most of the time, then > yes, could become a problem. > Kind regards > > > Le mercredi 3 septembre 2014 22:13:30 UTC+2, Josh Padnick a écrit : >> >> Hello Jaie, >> >> I'm posting about a year later on this thread, but we are using Play + >> Guice + jOOQ (which has been awesome so far), and having some issues with >> our transactions setup. I was wondering what you think of the following? >> >> - Initially, we defined a Guice interceptor to handle transactions >> for our service methods and our controllers. But we found that getting >> the >> Guice interceptor to catch exceptions thrown by the controller instance >> was >> difficult. >> - So we simplified and said "let's wrap every controller call in a >> transaction", and since we're going to be using Akka for some background >> processing, when Akka makes any database calls, we'll say "let's wrap >> every >> Actor send/receive in a transaction, too. >> >> The obvious benefit of all of this is simplicity, but I'm wondering if >> there are performance implications for making everything a transaction >> (initial Googling indicated no, but still researching). I also saw in a >> separate post that you're using Spring transactions. But what is really >> the benefit of all the muscle of Spring Transactions over just plain old >> boring controller and Akka wrappers? >> >> Thanks for your input! >> >> On Sunday, July 28, 2013 12:56:33 AM UTC-7, Lukas Eder wrote: >>> >>> Dear group, >>> >>> I would like to advertise a third-party piece of work by Jaie Wilson, >>> who has been creating a Play Framework integration for jOOQ: >>> https://github.com/jaiew/play-jooq >>> >>> This integration was discussed here in this issue: >>> https://github.com/jOOQ/jOOQ/issues/768 >>> >>> Feel free to join the discussion and provide feedback if you're using / >>> planning to use jOOQ with Play Framework >>> >>> Best Regards, >>> 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.
