Not that is important as far as the discussion about prevalence is concerned, but in my case I have console applications or windows services who are dealing with information received via messages. Think about a process that receives a message from a client, does some processing on the data and than it forwards it to some other entity. Theoretically, the application can crash right in the middle of the processing phase, situation in which the information is lost unless you save that intermediate state somewhere. With prevalence, I think, one does not need to save intermediate state, just for the fear it may get lost.
-----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of J. Merrill Sent: Friday, October 06, 2006 3:25 PM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Prevalent systems I haven't read the original thread that inspired you to go look at Prevalence, but ... If your "application state" isn't the same as "the contents of the application's database tables" (or whatever storage mechanism you're using for "saved data"), what is it that you're not storing that you think is important to have survive a reboot or crash? The list of open windows and their sizes? The possibly-modified order and sizes of the columns in a listview / grid display? The set of changes that the user made on the screen but that your application's UI design said should intentionally not be saved until the user indicates she's finished? If it's important to have work be recoverable before it's stored anywhere, perhaps it should be stored more frequently. What is the state you think you might need to recover? At 02:40 PM 10/6/2006, Eddie Lascu wrote >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: Frans Bouma >Sent: Friday, October 06, 2006 2:30 PM >To: [email protected] >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 J. Merrill / Analytical Software Corp =================================== 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® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
