I'm not a database expert, but the proprietary transactional one I've worked with will always log the incoming transaction before applying it. It's not a matter of specing a database for that, it's just what databases do. Isn't that the whole point of transactions? Once a client program gives a transaction to the DB and before it gets committed you must save that data in case of a system crash in that gap. If there is a crash, on a restart the DB applies what's in the log but not committed. So I would assume (perhaps wrongly) that saving application state as a transaction in a DB just works. A smart client will also have its own recovery mechanism for critical data (like that money you want in your bank).
Phil Wilson -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Lascu Sent: Friday, October 06, 2006 11:41 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Prevalent systems Frans, You may be right, but I wouldn't spec a DB just for that. After reading about prevalence, I understand that its scope is different: a cheap, fast and reliable way to preserve state. The challenge that I see is that you must design with that in mind. Even if the repository would be a database, rather than the prevalent layer, you would still need to recover from a crash and reestablish the state of the system prior to the shut down. In Bamboo's case, you gotta love the interception mechanism that routes all the operation through the prevalence layer so that they are logged before executed. All you need to do is to link your objects in the Prevalent Engine. How can this compare to placing the application state inside a RDB, using transaction logs? Regards, Eddie -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of Frans Bouma Sent: Friday, October 06, 2006 2:30 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Prevalent systems I always say: there must be a reason why systems like Oracle, DB2 and SqlServer use disk-based transaction logs. I.o.w.: IF you decide to place the application state inside a relational database (and why wouldn't you, they're designed for that), your application state is well protected and you have all the tools at hand to restore an application with an application state which is known to be solid and fully recovered. FB =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
