Hi Stéphane, Thanks very much for your detailed reply. Our performance needs are light enough for now that we can afford to open and close a connection with the full request, acknowledging there will be some waste, but there are some interesting ideas here.
Thanks again, Josh On Friday, September 5, 2014 4:29:37 AM UTC-7, Stéphane Cl wrote: > > > > Le jeudi 4 septembre 2014 19:45:03 UTC+2, Josh Padnick a écrit : >> >> 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. >> >> > There is not much you can do, other than obtaining a connection from the > pool only at the moment you actually need it rather than at the beginning > of a long running task, thus keeping your transactions as short as possible > which is a good practice anyway. Without any framework, It's easy to call > the static method DB.getConnection() in the middle of any task and wrap > this in a jooq factory, you just need some try/catch/finally blocks to do > the necessary cleaning yourself. > If you have more architectural constraints, you may also wrap this call in > a Provider interface that returns a connection, which you'd pass as a > dependency to your service, so that you don't reference play specific stuff > directly. > > > This may be more problematic if you are using an IoC container to inject > Services in your Controller, and if these services *require* an Sql > Connection at construction time. Maybe you could cheat your way with some > Lazy-auto-initialized Connection proxy, a quick google search lead me to > this : > > > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jdbc/datasource/LazyConnectionDataSourceProxy.html > > > or perhaps c3p0 also supports lazy connections? I have never tried any of > those approaches, I tend to stay away from magical frameworks when I have > specific needs. > > > >> 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(). >> >> > This is documented in Action composition : > https://www.playframework.com/documentation/2.2.x/JavaActionsComposition > > TransactionHandler is a class from my code, you use it via annotation and > it behaves like a servlet filter. It takes care of creating a factory and > setting autocommit to false, then it calls the delegate method (which is > the actual controller action) and disposes the connection. > I use it for most of my simple CRUD actions because it's convenient and it > eliminates the boilerplate required for simple transaction management. On > the other hand, I also have some non-annotated controllers that don't > automatically acquire connections from the pool. As explained above, I can > still obtain one manually if needed, but properly disposing it becomes the > responsibility of my code. The benefit of not doing that in > Global.onRequest is that you can easily decide per-controller if you prefer > using "connection per request" or "connection on demand" patterns. > >> -- 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.
