In the JTA case, the getConnection method must return the same connection associated with the transaction. No failing over.
-David On Apr 27, 2013, at 1:20 PM, Romain Manni-Bucau <[email protected]> wrote: > @David: works with jta case since connection is kind of singleton for this > case > > but clearly designed for read case > > that said a lot of db support better solution and service ip is easier to > handle if you have an admin team > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* > > > > 2013/4/27 David Blevins <[email protected]> > >> Had a quick look through the code and, definitely, it could only be used >> for read-only cases where no JTA transaction or transaction of any kind was >> needed. >> >> Anish, this doesn't sound at all like what you are after. You seem to be >> after a way to configure a feature on your DB2 driver itself. From just >> the description, it sounds like this driver will repeat the queries on all >> databases configured akin to a disk raid level 1 (mirroring). >> >> Can you verify with your DB administrators? >> >> >> -David >> >> On Apr 27, 2013, at 1:07 AM, Romain Manni-Bucau <[email protected]> >> wrote: >> >>> Hi >>> >>> Reproduced jboss behavior by.default. concretely: if getconnection fails >>> then try next db. >>> >>> I added strategy for read only cases (rdbms have an issue with write case >>> by design) >>> Le 27 avr. 2013 02:02, "David Blevins" <[email protected]> a >> écrit : >>> >>>> Noticed the work going on with TOMEE-912 and wanted to make sure it hit >>>> the dev list. >>>> >>>> Anish, if you have any insight on this feature request that'd be >>>> wonderful. Some questions: >>>> >>>> - Is this feature intended for use involving database writes and >>>> transactions? >>>> - Is this really load balancing rather than failure recovery? I.e. when >>>> should the functionality kick in, a or b or both? >>>> a) Load-balancing scenario: before starting a transaction, pick a >>>> datbase using some selection strategy (round-robin, random, sticky, >> etc.) >>>> b) Failure scenario: while in a transaction communicating with a >>>> databse, if it fails to respond then failover to another database using >>>> some selection strategy (round-robin, random, sticky, etc.) >>>> >>>> >>>> I can see A being very doable. Doing B could also possibly be doable as >>>> long as no writes were involved. >>>> >>>> If you have any information you can share about your setup that'd be >>>> wonderful. >>>> >>>> >>>> -David >>>> >>>> >>>> >>>> >> >>
