Hi, see my comments inline. On Tue, Dec 9, 2014 at 12:59 AM, Garret Wilson <[email protected]> wrote: > So I guess I still have questions about the whole thing. > > * So is ULTM really just a wrapper around JDBC Connection.commit() and > Connection.rollback()?
More or less. It is tracking the connections retrieved from the managed DataSource and when you call txManager.commit/rollback, it knows which connection to use for that purpose. The whole concept revolves around the fact that JDBC is a blocking API, so we can distinguish connections by threads using them. This is how "the magic" works, but there is no magic really. It's all as simple as ThreadLocal is (acting as mentioned connection tracker). > > * So how is TxManager.tx(...) different from DSLContext.transaction(...)? Is > it simply that I don't have to pass around a DSLContext? But don't I still > have to pass around a TxManager? (I consider a DI container still "passing > around" a TXManager---it's just that the DI container does the passing for > you.) The key difference comes from what I said above plus the fact that you can mix jOOQ with something else under the hood of one TxManager (but it's not important here, so let's skip it). What's important is that you can centralize transaction management in one place. That means there is no need to pass TxManager around. Of course you still can do it, and if you do, you use one instance of TxManager per application. The jOOQ transaction context is created when you start transaction and dies at the end, so you cannot just create it once and inject everywhere, you have to pass it around manually (adding it to method signatures) or build some kind of proxy, which, at the end, would lead you to the place where ULTM is, with the difference that ULTM does not depend on jOOQ, it's universal. > > * How does TxManager interact with DSLContext? If TxManager makes a > Connection.commit(), how do I know that the DSLContext is using the same > connection? How do I know that the DSLContext hasn't pulled another > connection out of the data pool? As I said above, when you use DataSource managed by ULTM to produce the DSLContext, ULTM will track connections used by DSLContext. jOOQ will be under control of ULTM which means the TxManager will be able to commit/rollback on connections the jOOQ were using. The only thing to remember is that in managed environments like this (same applies to EJB and Spring), you cannot jump from one thread to another while preforming the commit-able "unit of work". However, using different threads does not make sense when talking to databases through JDBC. > > * In fact I'm still unsure how DSLContext gets connections. One page > (http://www.jooq.org/doc/2.6/manual/sql-building/factory/connection-vs-datasource/) > seems to indicate that DSLContext will use a different connection for each > query. (Yes, I realize this documentation is really old, but Lukas, the link > there for 3.5 is broken. I finally found it; > http://www.jooq.org/doc/3.5/manual/sql-building/dsl-context/connection-vs-datasource/ > seems to say the same thing.) > DSLContext asks for connections from some kind of jOOQ's connection provider. It's part of API, but there is no need to implement it, because there is the DataSource adapter built-in. So, when you create DSLContext with DataSource, that DataSource becomes indirectly the connection provider. Since connections are tracked by ULTM - TxManager can do it's job. You can experiment like this: create TxManager and managed DataSource, create DSLContext using that datasource. Modify the data using jOOQ then manually fetch the JDBC connection from that DataSource and you will get exactly the same one used by jOOQ. You can use that connection to modify something else, then txManager rollback will revert both changes of what you have done with jOOQ and connection itself. > I realize I have asked some of these questions before, but the answers never > seem to tie together and we've been trying to release a new product and I've > been doing construction in a new apartment in another country (not in my > native language) and my mind is about to become frazzled... > > Garret I hope it's a little bit clearer right now. You asked good questions here, maybe I should create some kind of wiki based on those... I wish I were better organized... Regards, Witold Szczerba > > > On 12/8/2014 3:06 PM, Witold Szczerba wrote: >> >> Hi, >> you should have one ULTM (TxManager + managed DataSource) per >> application (assuming you have only one database). >> >> What seems strange to me is why do you use >> "DSL.using(getConfiguration())" everywhere instead of creating >> DSLContext once and use that everywhere? There is no need to create it >> all the time, one instance should be enough. >> >> Do you use DI? It's brilliant design pattern. The basic idea is to >> split object creation code from business logic, so I create TxManager >> and DSLContext once and inject it everywhere I need (using Guice or if >> you do not want it, by manually creating and configuring objects when >> bootstrapping application). It works flawlessly. >> >> There is no need to pass TxManager everywhere. I would use it on some >> external layer, like some gateway, to begin and commit or rollback, >> but your case can be a little bit different, so I cannot tell. >> Referring to your example with CarManager and WheelManager, it would >> look odd to operate with TxManager in one and not use it in another >> (but you can do this). However, I would think about getting rid of >> transaction management from those manager, because if you start >> transaction yet elsewhere, in some ThirdManager, then you cannot call >> CarManager (because it handles transactions by itself) but you can >> call WheelManager (because it doesn't). >> >> In my app, there is only one "point of entry", but there might be many >> (like JAX-RS endpoints). >> >> There is no mailing list for ULTM, but fell free to ask question on >> issue tracker, because I am not sure if people here are interested :) >> >> Regards, >> Witold Szczerba > > > -- > 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.
