Do you have a test showing it is not the case? Le 28 avr. 2013 01:22, "David Blevins" <[email protected]> a écrit :
> 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 > >>>> > >>>> > >>>> > >>>> > >> > >> > >
