db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Created: (DERBY-218) Add Relaxed Durability option
Date Thu, 14 Apr 2005 16:22:37 GMT
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...


RPost wrote:

>>Dibyendu Majumdar wrote:
>>From: "Mike Matrigali" <mikem_app@sbcglobal.net>
>>> 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.

View raw message