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()?
* 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.)
* 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?
* 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.)
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 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.
