2016-12-10 16:36 GMT+01:00 Rob Sargent <robjsarg...@gmail.com>: > > > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo <t.dalpo...@gmail.com> wrote: > > > > Hi, > > I'd like to do that! But my DB must be crash proof! Very high > reliability is a must. > > I also use sycn replication. > > Regards > > Pupillo > > > > > > > > > > Are each of the updates visible to a user or read/analyzed by another > activity? If not you can do most of the update in memory and flush a > snapshot periodically to the database. > > > > > > This list discourages top posting. You’re asked to place your reply at the > bottom > > You haven’t laid out you’re application architecture (how many clients, > who is reading who is writing, etc). Caching doesn’t mean your database is > any less crash proof. At that rate of activity, depending on architecture, > you could lose updates in all sorts of crash scenarios.
As for crash proof, I meant that once my client app is told that her update request was committed, it mustn't get lost (hdd failure apart of course). And I can't wait to flush the cache before telling to the app :"committed". I can replicate also the cache on the standby PC of course. Regards Pupillo
