Another example is if you want to be able to recover state for a web server/app server user session somewhere . Storing on disk has a huge performance impact, but if you have transactional semantics and an asynchronous backing store, that's pretty good. If there is the rare chance that all the session data is lost for some reason, that's OK, it just means users have to re-establish sessions, it's not loss of critical data.

Certain telco apps don't mind data either such as the location of cell phones, this gets re-established pretty quickly as the phones ping back into the system again... They're willing to take this risk to get the response time they need -- many telco apps store their data purely in memory, often with some kind of replication scheme...

David

RPost wrote:

Dibyendu Majumdar wrote:
From: "Mike Matrigali" <[EMAIL PROTECTED]>

From responses to Dan's original post on building a system with the
sync options disabled it seemed like there was enough response that
those options should be made available.  I admit I am worried because
this system can no longer guarantee recoverability.  It would be
interesting to know how people would use such a configuration.

I agree with you that a database system without recoverability is useless.


One use for a database without recoverability is for data
warehousing/reporting.

The database used as a datamart needs to be created without error but once
created the core tables can be read-only. Other read/write tables will be
used for searches, match-engine results and temporary tables to support
report-ready processes. Loss of data in these tables would not be serious
since they start out empty at the start of a process anyway.

Reply via email to