Interesting, thanks for the response, Bjorn!
On Sun, Mar 24, 2013 at 4:47 PM, Bjorn Danielsson < [email protected]> wrote: > Howard, > > I use a single shared SQL service backend for several TomEE > instances. In the production environment this will most likely > be a managed cloud SQL service. > > There are two aspects of "failover" in my case. The first is > failover at the web service end, which is straight-forward to > handle via a frontend proxy or DNS switcher or something like > that. The second is failover for polling of my persistent queue. > This function could in principle be load-balanced between the > cluster instances, but that just results in a huge amount of > optimistic-lock collisions. So instead I let one TomEE instance > poll the queue, and if it dies one of the other instances takes > over when this condition is detected (via the SQL database). > > I don't use any kind of session replication. I do use servlet > sessions for some things but mainly as a cache for things that > can also be found via a combination of cookies and SQL storage. > > -- > Bjorn Danielsson > Cuspy Code AB > > > "Howard W. Smith, Jr." <[email protected]> wrote: > > Bjorn, for some time now, i've been wondering how to have 2 separate > TomEE > > servers (for failover) and one copy of your database per TomEE? are you > > replicating database via tomee/tomcat session replication? > > > > sometime ago, i searched google about this, but honestly... i don't > > understand how to replicate database in cluster environment. i am using > > eclipselink as jpa provider, and i think i saw something related to > > cluster/replication via eclipselink. i couldn't find any blogs or > anything > > out there talking about this subject much. :( > > > > > > On Sun, Mar 24, 2013 at 1:35 PM, Bjorn Danielsson < > > [email protected]> wrote: > > > >> Well, I still have networking between my two (for failover) > >> TomEE servers and the SQL service that holds the queue and > >> commits the transactions. But I eliminated a middle-man :) > >> > >> -- > >> Bjorn Danielsson > >> Cuspy Code AB > >> > >> > >> Romain Manni-Bucau <[email protected]> wrote: > >> > Yes, you squeezed the network layer, you avoided network problems ;) > >> > Le 24 mars 2013 18:12, "Bjorn Danielsson" < > >> [email protected]> > >> > a écrit : > >> > > >> >> Interesting, I went the opposite way, from JMS to @Asynchronous. > >> >> > >> >> I began using JMS for asynchronous requests that were required > >> >> to be transactional and reliable. This worked great during > >> >> initial development, first with OpenMQ in GlassFish and then > >> >> with ActiveMQ in OpenEJB/TomEE. But when I started testing > >> >> ActiveMQ failover configurations under heavy loads, I started > >> >> getting lost messages and hung JMS connections. > >> >> > >> >> So after struggling for a while I ended up rolling my own > >> >> persistent queue in SQL, and used @Asynchronous for the request > >> >> dispatch. That turned out to solve all of my problems, and the > >> >> overall configuration also become notably simpler. > >> >> > >> >> -- > >> >> Bjorn Danielsson > >> >> Cuspy Code AB > >> >> > >> >> > >> >> "Howard W. Smith, Jr." <[email protected]> wrote: > >> >> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau > >> >> > <[email protected]>wrote: > >> >> > > >> >> >> just to be sure: @Schedule != @Asynchronous > >> >> >> > >> >> >> > >> >> > True/understood. hahaha! > >> >> > > >> >> > My point is this... since i had issues using @Asynchronous, it is > hard > >> >> > going back to @Asynchronous since i'm loving AMQ/JMS. :) > >> >> > > >> >> > I think I heard you and/or others say that JMS is old technology > >> (java ee > >> >> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous > >> can > >> >> do > >> >> > the job, but i even heard that @asynchronous is not good to use in > >> JSF or > >> >> > servlet (request-based) apps. > >> >> > >> >
