DB replication basically works with the transaction log (IBM DB/2 terminology, in Oracle it's called transfer tables). Each update/insert/delete statement gets written into a file and you can pick this file up from another node. This secondary node then does exactly the same like the first node. See e.g. Master/Slave setup on MySQL. Means after a commit, after a few ms the secondary (slave) node has exactly the same info as the master node. And if the master node fails, then you can easily fall over to the slave node.
This can also be very helpful to 'scale out' in case you need performance: All write stuff is only performed on the master node, but expensive queries/searches might be performed on the n replication nodes. Of course this needs a special handling in your app, but allows to move the expensive queries away from your primary node. All other 'real' cluster solutions are really expensive and most of the times not worth the hassle imo ;) LieGrue, strub PS: usually clustering of Servlets are done by just 'pairing' up always 2 different servlet containers (tomcat nodes A+B, C+D) and have full session replication on them. Means whenever a request is done it will move the whole session content to the paired node. With the msm you can get away from this. ----- Original Message ----- > From: "Howard W. Smith, Jr." <smithh032...@gmail.com> > To: MyFaces Discussion <users@myfaces.apache.org> > Cc: > Sent: Sunday, 20 October 2013, 12:56 > Subject: Re: [OT but still JSF]: Clustering, session replication, and > database, too > > also, i'm still wondering about how database is replicated while clustering > the app. > > > On Sun, Oct 20, 2013 at 5:34 AM, Thomas Andraschko < > andraschko.tho...@gmail.com> wrote: > >> JFYI: >> MyFaces+OWB on Tomcat with MSM is working fine. >> >
