Hi Alok 2015-05-19 12:35 GMT+02:00 Alok Menghrajani <[email protected]>:
> Thanks for your response, very helpful. > > I'm experimenting with [1]. I'm still figuring out which transaction > level I need to set and making sure that my TransactionProvider > implements the desired behavior. > > A few things I figured might be worth sharing: > > 1. I'm using a counter and plan to only commit the top-level > transaction. I'm keeping the counter in ctx.configuration().data() > (which is very similar to DefaultTransactionProvider's behavior, > except that has a Stack). That sounds exactly like what we intend to implement in https://github.com/jOOQ/jOOQ/issues/3955 > It looks like the > DefaultTransactionProvider's savepoints() method is not thread safe. > Do TransactionProviders need to care about concurrent calls to > begin()? I'm guessing it's unlikely that a transaction gets shared > between different threads, but I'm no expert. > All the transaction models I'm aware of tightly couple transactions to single threads. In fact, a thread is usually "blocked" by a transaction and returns to the thread pool no earlier than at the end of a transaction, possibly later. This model works well with classic Servlet models, where an HTTP request also "blocks" a thread until the request is finished. "Reactive programming" (as understood by Typesafe et al.) tries to minimise thread contention by sharing threads among requests. In these models, transactions can jump between threads, and the "action" model will need to take care that no transaction parts leak the action, and thus the thread. Chances are, that within the bounds of a transaction, you do not have to be thread safe. Note though, that DefaultTransactionProvider.savepoints() is "thread safe" as loosely specified by TransactionProvider ( http://www.jooq.org/javadoc/latest/org/jooq/TransactionProvider.html): A new Configuration <http://www.jooq.org/javadoc/latest/org/jooq/Configuration.html> copy is created from the calling DSLContext <http://www.jooq.org/javadoc/latest/org/jooq/DSLContext.html> for the scope of a single transactions. Implementors may freely add custom data to Configuration.data() <http://www.jooq.org/javadoc/latest/org/jooq/Configuration.html#data-->, in order to share information between begin(TransactionContext) <http://www.jooq.org/javadoc/latest/org/jooq/TransactionProvider.html#begin-org.jooq.TransactionContext-> and commit(TransactionContext) <http://www.jooq.org/javadoc/latest/org/jooq/TransactionProvider.html#commit-org.jooq.TransactionContext-> orrollback(TransactionContext) <http://www.jooq.org/javadoc/latest/org/jooq/TransactionProvider.html#rollback-org.jooq.TransactionContext->, as well as to share information with nested transactions. I suspect that the thread safety discussion deserves more attention in the Javadocs. I have registered an issue to improve the Javadocs: https://github.com/jOOQ/jOOQ/issues/4289 2. I don't think DefaultTransactionProvider needs to have a Connection > instance variable. The brace() method could just use the connection > already stored in the map? > You're probably right, I'll investigate. This will be tracked as https://github.com/jOOQ/jOOQ/issues/4290 > 3. What is the purpose of the data() map in TransactionContext? > To store data that should be available between begin() and commit() / rollback(). All org.jooq.Scope implementations have such a Map that can be used to keep user data around for the respective lifetime of the Scope > 4. I was initially not creating a new jooq context inside the > transaction (DSL.using(configuration)). I have the feeling the API > would be less error prone if TransactionalRunnable and > TransactionalCallable took a DSLContext instead of a configuration > (the configuration object would be available via the > context.configuration method if needed). > The DSLContext type is not really an expressive type on its own. Having that as a function argument may seem convenient, but it doesn't really make sense. I see your point, and I believe that the main criticism by Witold Szczerba in various past discussions on this user group (e.g. https://groups.google.com/d/msg/jooq-user/-2laC-pYsbI/qz23wRhe5C4J) stemmed from this very fact. It would actually be convenient if the functional argument types would have no arguments at all, as implemented by Witold's ULTM library, which puts the context in a ThreadLocal (I believe). I believe that the current API will show its value in the long run, as it 1) makes no assumptions about the transaction model 2) stays completely generic via using Configuration arguments I hope this makes things a bit clearer? -- 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.
