Hi, thanks for pointing this out, completely forgot this registry!!! Thanks David.
About git: we should more largely discuss our "infra" choices IMO (typically maven compiler plugin has big issues ATM with version we use so we have to address it or decide to go ahead using gradle which can ease our tomee modules which are not really "under convention"), i'm rather for git today since that's the 4th time i need it and feel a bit naked with svn. IMO it will be worse when we'll fork to work on JavaEE 7 so maybe the moment *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/29 David Blevins <david.blev...@gmail.com> > You're getting closer with the last two commits. You'll want to remove > that map that uses the Transaction object as a key. There's an object > provided by the TransactionManager for doing this kind of registering and > does all required cleanup as well, so there can be no leaks. > > See the code just after the slide titled "The DataSource You Get". The > object you want is the TransactionSynchronizationRegistry > > > http://tomee.apache.org/presentations/2012_JAXConf_Tomcat_to_JavaEE_with_TomEE.pdf > > I suspect you're still hacking, but ReverseFailOverRouterTest and > FailOverRouterTest now fail. Sometimes I wonder if we wouldn't be better > off with git. Only so many people can experiment on trunk like this -- > basically one. Not really a pressing issue now, but something to think > about when we get more active people. > > > -David > > > On Apr 28, 2013, at 12:22 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Do you have a test showing it is not the case? > > Le 28 avr. 2013 01:22, "David Blevins" <david.blev...@gmail.com> 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 <rmannibu...@gmail.com> > >> 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 <david.blev...@gmail.com> > >>> > >>>> 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 < > rmannibu...@gmail.com> > >>>> 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" <david.blev...@gmail.com> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
