Interesting. thanks Jean-Louis. Let me share some things. When I saw Romain's response on the other thread that informed me about tomee/openejb failover via dynamic datasource(s), I saw his post/blog mention load-balancing, and that is what attracted me the most to this feature.
So, after I added it to my tomee.xml (earlier this morning, my time), I wanted to test the 'load-balancing' just a bit, I started a long-running query that searches multiple tables for a certain string (varchar type), and after starting that query, I did a multiple-table commit of at least 4 rows in an 'orders' table that is related to many other tables. the commit consists of doing non-read-only queries that read 'orders' and the multiple tables, and then copies the data (or insert the data into multiple tables). i was quite impressed that the commit took less than 2 seconds maybe (on my development server), which is not as fast as my production server, and plus, my drive is drastically fragmented, since I have been doing JSF web app development for 2 years straight, building building building and have not defragged or reformatted (or replaced) my hard drive... the commit occurred during the long-running query, and the query finished some # of seconds after I was mouth-wide-opened (shocked) at the fact that the data committed 'during' the long-running query. but you know what? what was more even a shock to me was this... all of the above was on my test/development server (locally here at my home), so before updating production server (at another location), I decided to login to production app, and run the same test. please note/remember, production app was 'not' configured to use tomee/openejb failover via dynamic datasource(s). when I ran the same test, while connected (remotely) to the production app, the test results were...exactly the same. that was very shocking. that is why my earlier response... that it works... i was not so 'excited' as I am 'usually'. lol...please continue to listen... i had wrote a very shocking email, and was very excited to report that the 1st test (on development server) was very impressive, but then after I ran the same test (remotely) against the production server (that does not have tomee failover), I backspace'd my response, and changed my response to a less-excited tone. i know that i have strived to make my app perform well, and I just want the database to not be the bottleneck in the app. after performing the remote test against production server, I went ahead and configured tomee/openejb failover via dynamic datasources on the production server (in tomee.xml), and copied the database, once, so now the app is connected to 2 databases. I want to test tomee/openejb failover via dynamic datasources by running it...in production, on production server, and see what the test results will be. can/shall i assume that this is a form of replication? Jean-Louis, you mentioned something like it targets the readonly requirement and I think you said transactions are not shared. i assume the data is replicated somehow. right? thanks for listening and responding. :) On Sun, Nov 3, 2013 at 10:51 AM, Jean-Louis MONTEIRO <jeano...@gmail.com>wrote: > Well, we pushed that feature some years ago already. > We mainly used it to implement a failover mechanism, or to implement kinda > cloud features, I mean having each customer data in different databases. > Also the read mostly pattern AFAIR. > > Restrictions are mainly transactions not shared and not wrapping > connections from more than one datasource. > The cache configuration must be well configured to not cache stale data. > But it clearly depends on the use case. > > Hope that helps. > > JLouis > > > 2013/11/3 Howard W. Smith, Jr. <smithh032...@gmail.com> > > > okay, and one last question, is there a bit more documentation on the > > following, so we can know what to expect, and the implementation is quite > > sound, working as designed and no known issues with the following? > > > > <ul> > > <li>default: the first is used while possible and others datasources are > > just backup, this is typically the failover case</li> > > <li>random: any datasource of the list is used</li> > > <li>reverse: between two call to a method the list is reversed</li> > > <li>round-robin[%N]: round robin between datasources, you can specify how > > many step you browse between two calls using N (default is 1)</li> > > </ul> > > > > i saw the limitations on the referenced pages (dynamic datasources), but > I > > didn't see any known issues in your/Romain's post/blog. > > > > please excuse my ignorance, if I have not heard or seen much chatter > about > > this on the mail list. I usually try to pay attention to almost all tomee > > emails, especially those that interest me the most. :) > > > > > > > > > > On Sun, Nov 3, 2013 at 10:22 AM, Romain Manni-Bucau > > <rmannibu...@gmail.com>wrote: > > > > > If you dont use it then thats ok. We close the pool then, not > connections > > > Le 3 nov. 2013 16:19, "Howard W. Smith, Jr." <smithh032...@gmail.com> > a > > > écrit : > > > > > > > FYI, I just stopped my local tomee, and recognized that my > @Application > > > > @PreDestroy has my code that stops Apache Derby prior to main and > > > fallback > > > > datasources are closed. > > > > > > > > is this okay? > > > > > > > > Nov 03, 2013 10:12:48 AM org.apache.catalina.core.StandardServer > await > > > > INFO: A valid shutdown command was received via the shutdown port. > > > Stopping > > > > the Server instance. > > > > Nov 03, 2013 10:12:48 AM org.apache.coyote.AbstractProtocol pause > > > > INFO: Pausing ProtocolHandler ["http-nio-8080"] > > > > Nov 03, 2013 10:12:48 AM org.apache.coyote.AbstractProtocol pause > > > > INFO: Pausing ProtocolHandler ["ajp-bio-8009"] > > > > Nov 03, 2013 10:12:48 AM org.apache.catalina.core.StandardService > > > > stopInternal > > > > INFO: Stopping service Catalina > > > > Nov 03, 2013 10:12:48 AM pf.LoginFilter destroy > > > > INFO: ... > > > > Nov 03, 2013 10:12:48 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyApplication > > > > INFO: Undeploying app: > > > C:\apache-tomee-plus-1.6.0-SNAPSHOT\webapps\mcmsweb > > > > Nov 03, 2013 10:12:48 AM pf.ApplicationScopeBean destroy > > > > INFO: BEGIN > > > > Nov 03, 2013 10:12:48 AM utils.database.DerbyUtil shutdown > > > > INFO: DerbyUtil.java: shutdown() invoked > > > > Nov 03, 2013 10:12:48 AM utils.database.DerbyUtil loadDriver > > > > INFO: DerbyUtil.java: loadDriver(): Loaded driver > > > > (org.apache.derby.jdbc.EmbeddedDriver) successfully > > > > Nov 03, 2013 10:12:48 AM utils.database.DerbyUtil shutdown > > > > INFO: DerbyUtil.java: shutdown(): Derby shut down normally > > > > Nov 03, 2013 10:12:48 AM pf.ApplicationScopeBean destroy > > > > INFO: gCalUtil.shutdown() completed > > > > Nov 03, 2013 10:12:48 AM pf.ApplicationScopeBean destroy > > > > INFO: jodConverter.shutdown() completed > > > > Nov 03, 2013 10:12:48 AM mdb.ApplicationMessageBean shutdown > > > > INFO: ApplicationMessageBean.shutdown() BEGIN > > > > Nov 03, 2013 10:12:48 AM mdb.ApplicationMessageBean shutdown > > > > INFO: ApplicationMessageBean.shutdown() END > > > > Nov 03, 2013 10:12:48 AM pf.ApplicationScopeBean destroy > > > > INFO: applicationMessageBean.shutdown() completed > > > > Nov 03, 2013 10:12:48 AM pf.ThreadLocalImmolater immolate > > > > INFO: immolated 305 values in ThreadLocals > > > > Nov 03, 2013 10:12:48 AM pf.ApplicationScopeBean destroy > > > > INFO: END > > > > Nov 03, 2013 10:12:48 AM > org.apache.activemq.ra.ActiveMQEndpointWorker > > > stop > > > > INFO: Stopping > > > > Nov 03, 2013 10:12:48 AM > org.apache.activemq.ra.ActiveMQEndpointWorker > > > stop > > > > INFO: Stopping > > > > [EL Info]: 2013-11-03 > > > > > > > > > > > > > > 10:12:48.682--ServerSession(1206174612)--file:/C:/apache-tomee-plus-1.6.0-SNAPSHOT/webapps/mcmsweb/WEB-INF/classes/_mcmsPU > > > > logout successful > > > > Nov 03, 2013 10:12:49 AM org.apache.catalina.loader.WebappClassLoader > > > > clearReferencesThreads > > > > SEVERE: The web application [/mcmsweb] appears to have started a > thread > > > > named [PoolIdleReleaseTimer] but has failed to stop it. This is very > > > likely > > > > to create a memory leak. > > > > Nov 03, 2013 10:12:49 AM org.apache.catalina.loader.WebappClassLoader > > > > clearReferencesThreads > > > > SEVERE: The web application [/mcmsweb] appears to have started a > thread > > > > named [ActiveMQ VMTransport: vm://localhost#5-5] but has failed to > stop > > > it. > > > > This is very likely to create a memory leak. > > > > Nov 03, 2013 10:12:49 AM org.apache.catalina.loader.WebappClassLoader > > > > clearReferencesThreads > > > > SEVERE: The web application [/mcmsweb] appears to have started a > thread > > > > named [ActiveMQ VMTransport: vm://localhost#5-6] but has failed to > stop > > > it. > > > > This is very likely to create a memory leak. > > > > Nov 03, 2013 10:12:49 AM org.apache.catalina.loader.WebappClassLoader > > > > clearReferencesThreads > > > > SEVERE: The web application [/mcmsweb] appears to have started a > thread > > > > named [ActiveMQ VMTransport: vm://localhost#4-4] but has failed to > stop > > > it. > > > > This is very likely to create a memory leak. > > > > Nov 03, 2013 10:12:57 AM org.apache.coyote.AbstractProtocol stop > > > > INFO: Stopping ProtocolHandler ["http-nio-8080"] > > > > Nov 03, 2013 10:12:57 AM org.apache.coyote.AbstractProtocol stop > > > > INFO: Stopping ProtocolHandler ["ajp-bio-8009"] > > > > Nov 03, 2013 10:12:57 AM > org.apache.openejb.server.SimpleServiceManager > > > > stop > > > > INFO: Stopping server services > > > > Nov 03, 2013 10:12:57 AM org.quartz.core.QuartzScheduler shutdown > > > > INFO: Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB shutting > down. > > > > Nov 03, 2013 10:12:57 AM org.quartz.core.QuartzScheduler standby > > > > INFO: Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB paused. > > > > Nov 03, 2013 10:12:57 AM org.quartz.core.QuartzScheduler > unregisterJMX > > > > INFO: Scheduler unregistered from name > > > > > > > > > > > > > > 'quartz:type=QuartzScheduler,name=OpenEJB-TimerService-Scheduler,instance=OpenEJB' > > > > in the local MBeanServer. > > > > Nov 03, 2013 10:12:57 AM org.quartz.core.QuartzScheduler shutdown > > > > INFO: Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB shutdown > > > complete. > > > > Nov 03, 2013 10:12:57 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyApplication > > > > INFO: Undeploying app: openejb > > > > Nov 03, 2013 10:12:57 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyResource > > > > INFO: Closing DataSource: main > > > > Nov 03, 2013 10:12:57 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyResource > > > > INFO: Closing DataSource: fallback > > > > Nov 03, 2013 10:12:57 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyResource > > > > INFO: Stopping ResourceAdapter: Default JMS Resource Adapter > > > > Nov 03, 2013 10:12:57 AM > > > > org.apache.openejb.resource.activemq.ActiveMQResourceAdapter stop > > > > INFO: Stopping ActiveMQ > > > > Nov 03, 2013 10:12:58 AM > > > > org.apache.openejb.resource.activemq.ActiveMQResourceAdapter stopImpl > > > > INFO: Stopped ActiveMQ broker > > > > Nov 03, 2013 10:12:58 AM > org.apache.openejb.assembler.classic.Assembler > > > > destroyResource > > > > INFO: Closing DataSource: Default Unmanaged JDBC Database > > > > Nov 03, 2013 10:12:58 AM org.apache.coyote.AbstractProtocol destroy > > > > INFO: Destroying ProtocolHandler ["http-nio-8080"] > > > > Nov 03, 2013 10:12:58 AM org.apache.coyote.AbstractProtocol destroy > > > > INFO: Destroying ProtocolHandler ["ajp-bio-8009"] > > > > > > > > > > > > > > > > On Sun, Nov 3, 2013 at 9:55 AM, Howard W. Smith, Jr. < > > > > smithh032...@gmail.com > > > > > wrote: > > > > > > > > > okay, i set it up as your post demonstrated, I tested already, and > I > > > see > > > > > no issues. it's time to test this in production. :) > > > > > > > > > > thanks romain! like i said in the other thread, I wish I knew about > > > this > > > > > earlier. > > > > > > > > > > > > > > > > > > > > On Sun, Nov 3, 2013 at 9:16 AM, Howard W. Smith, Jr. < > > > > > smithh032...@gmail.com> wrote: > > > > > > > > > >> So, the following replaces service-jar.xml (as per your post)? > > > > >> > > > > >> <Resource id="jdbc/ds" type="DataSource" > > provider="RoutedDataSource"> > > > > >> router = failover-router > > > > >> </Resource> > > > > >> > > > > >> and if I wanted to use the 'strategy' parameter, I would add to > > > Resource > > > > >> as demonstrated below? > > > > >> > > > > >> <Resource id="jdbc/ds" type="DataSource" > > provider="RoutedDataSource"> > > > > >> router = failover-router > > > > >> strategy = random > > > > >> </Resource> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On Sun, Nov 3, 2013 at 8:58 AM, Romain Manni-Bucau < > > > > rmannibu...@gmail.com > > > > >> > wrote: > > > > >> > > > > >>> Hi > > > > >>> > > > > >>> Failover is native but to customiee the algo you can code > anything > > > you > > > > >>> want > > > > >>> > > > > >>> Tomee.xml is openejb.xml > > > > >>> > > > > >>> Service-jar.xml is today useless (see my post) > > > > >>> Le 3 nov. 2013 14:55, "Howard W. Smith, Jr." < > > smithh032...@gmail.com > > > > > > > > a > > > > >>> écrit : > > > > >>> > > > > >>> > First of all, thanks Romain for recommending the following, and > > for > > > > >>> that I > > > > >>> > will gladly start a new thread. :) > > > > >>> > > > > > >>> > TomEE/OpenEJB and failover of datasources[1] > > > > >>> > > > > > >>> > which references > > > > >>> > > > > > >>> > [OpenEJB] Dynamic Datasource[2] > > > > >>> > > > > > >>> > but I found the following TomEE example: > > > > >>> > > > > > >>> > [TomEE] Dynamic Datasource Routing[3] > > > > >>> > > > > > >>> > So, before I begin, my questions are as follows: > > > > >>> > > > > > >>> > 1. I recognized that failover[1] says that the idea is to > 'reuse' > > > > >>> dynamic > > > > >>> > datasource. Does this mean that we should code openejb[2] or > > > tomee[3] > > > > >>> > dynamic datasource, first, and then reference accordingly via > > > > >>> failover[1]? > > > > >>> > > > > > >>> > 2. or failover[1] requires no coding on our part? only > developer > > > > needs > > > > >>> to > > > > >>> > setup the failover 'config'? > > > > >>> > > > > > >>> > 3. also, tomee[3] dynamic datasource routing recommends > > openejb.xml > > > > >>> > (instead of tomee.xml). can openejb.xml cofiguration be placed > in > > > > >>> > tomee.xml, too, or not? > > > > >>> > > > > > >>> > 4. okay, never mind, I was abouto ask for some clarification > > about > > > > >>> > META-INF/org.router/service-jar.xml, but I 'found' > > service-jar.xml > > > on > > > > >>> > trunk[4]. :) > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > [1] > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > http://rmannibucau.wordpress.com/2013/04/26/tomeeopenejb-and-failover-of-datasources/ > > > > >>> > > > > > >>> > [2] http://tomee.apache.org/dynamic-datasource.html > > > > >>> > > > > > >>> > [3] > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > http://tomee.apache.org/examples-trunk/dynamic-datasource-routing/README.html > > > > >>> > > > > > >>> > [4] > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > http://svn.apache.org/repos/asf/tomee/tomee/trunk/examples/dynamic-datasource-routing/src/main/resources/META-INF/org.router/service-jar.xml > > > > >>> > > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > -- > Jean-Louis >
