Comments on: How we got rid of the database–part 2

By: Rinat Abdullin

Rinat Abdullin — Thu, 05 Jul 2012 02:04:00 +0000

@nyxiscoo1:disqus , failure detection is handled at slightly higher level in this approach. In essence, if server blows up, while we are in the middle of message processing (either command message or event message), then this will mean that message itself was not handled (and hence not removed from the queue).
This will mean that next time server starts up – it will automatically try to process the message again, hitting the failed event store and throwing up a real exception.

BTW, I’m currently testing alpha version of the next version of file event store, which should be able to provide better performance and better handling of random server fails. Latest version is currently available in lokad-iddd-sample at github.

By: Anonymous

Anonymous — Wed, 04 Jul 2012 18:37:00 +0000

Since I did not yet have any time to verify your findings I forwarded your concern to the author of the Lokad.CQRS “framework” Rinat Abdullin. I will also have another look myself.

By: Anonymous

Anonymous — Wed, 04 Jul 2012 18:04:00 +0000

Hi Gabriel,
I’ve looked at FileTapeStream and other implementation of storages at Lokad.CQRS, and it turned out thet they are absolutely not fail safe.

For example: if unexpected system reboot occured at the time of writing event, and last record was just partially written, FileTapeStream will throw exception on attempt to load such file. And as a result of using one file per aggreagation root you’ll receive this error only next time this root will be addressed.

Have you any mechanism to prevent this?

Sorry for my english)

By: Anonymous

Anonymous — Fri, 15 Jun 2012 16:15:00 +0000

gnschenker at gmail dot com

By: Nikos Maravitsas

Nikos Maravitsas — Fri, 15 Jun 2012 14:46:00 +0000

Hi Gabriel,

Great post! Is there an email address I can contact you in private?

By: Nick

Nick — Fri, 15 Jun 2012 07:33:00 +0000

I’ll wait till you’ve finished your posts and I understand it better before I ask more questions.

See you soon

By: Anonymous

Anonymous — Thu, 14 Jun 2012 16:55:00 +0000

I do not yet know how many posts will follow. This is not a book where I have to pre-plan the chapters
The color schema is the dark them in Visual Studio 2012

By: Anonymous

Anonymous — Thu, 14 Jun 2012 16:55:00 +0000

Reporting follows the exact same principles are querying for the screen – just the screen is replaced by paper and the output is usually much longer (many pages)

By: Peter

Peter — Thu, 14 Jun 2012 15:43:00 +0000

I really like this series! How many parts are you planning to write? A little off but I like your color theme. What’s its name?

By: Anonymous

Anonymous — Thu, 14 Jun 2012 13:21:00 +0000

Usually the write side is not the first thing you need to scale since write operations are much less frequent than read operations (at least a factor of 1 to 10!). If you still need to scale the write side you can partition by e.g. aggregate type