The big difference is speed .. I use a prevalence layer on one of my applications that has updates happenning to the object graph hundreds to thousands of times a second. The only reason I even need a prevalence layer is so if I crash I can start up where I left off and the benchmarks show prevalence being orders of magnitude faster than dealing with the database (3000-9000 times faster). I have no need for concurrency (single app) and I don't to pay for a database license nor do I gain the point of failure it brings (my employer keeps getting happier)
There seem to be alot of misconceptions about prevalence .. every change is updated as it is done automatically there is no "saving" ... there is snap shotting but this is quite different than saving .. the state is already saved in the transactional log. When it comes to referential integrity throughout your graph you are correct that it can become troublesome as you may have changes that span multiple objects and a crash in between could leave you in a state that does not make sense. You can easily work around this in your own code although some prevalence layers support transactional writing (I forget if bamboo does or not). Bamboo is certainly not the only prevalence layer around butit is a greta intro to the concept. Cheers, Greg On 10/6/06, Eddie Lascu <[EMAIL PROTECTED]> 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: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of 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 =================================== 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
-- If knowledge can create problems, it is not through ignorance that we can solve them. Isaac Asimov =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
