Atomikos Forum |
|
Hi
Hi Looks like PropagationMessage has a hardcoded retry count of 5. Is there any way to configure this ? And to configure the Propagator retry interval ? (Propagator.RETRY_INTERVAL is hardcoded at 10secs) And the threadpool implementation too ? Those values do not seem configurable looking at the code, but maybe I overlooked something. /jog
Well, I'll let you decide:
The retry count & timeout should depend on an external condition: how much time are you willing to let the user wait to get a final answer on his transaction? In the problem I'm working on, where transactions are mainly used to ensure consistency of the data (we use transactions to coordinate several resources), without any need for crash recovery (we disable the transaction logs), and where the responsiveness of the application is of prime importance, we don't want the user to wait 5 * 10 secs before getting the result. We'd prefer fail fast and rollback. The other use case if for unittesting: in my tests (where I found that issue), I'm testing for proper rollback and I'm forced to wait those 50secs for the test to complete. For thread pooling, as we (would) run Atomikos in our own container, we manage the threads ourself and would like to plug our thread pools into the transaction management layer. One reason is for logging - we wan't to be able to push some contextual information on the thread local storage. Another is for monitoring - we want to be able to monitor thread pool state, to detect stale threads (threads that were not returned to the pool). /jog |