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 >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
