Memstate is a complete redesign of OrigoDB with major improvements in key areas such as performance, availability, licensing, cross-platform, docker and cloud support.
Performance - OrigoDB can process up to 3K write transactions per second, Memstate can process up to 100K, a 33x improvement!
High Availability - An OrigoDB cluster has a single primary and one or more read-only replicas. If the primary fails one of the replicas can be promoted to new primary but this requires manual intervention. Nodes in a Memstate cluster are all read/write.
Licensing - OrigoDB Server is a commercial offering while Memstate server is OSS and free for commercial use.
Cross platform - Memstate targets .NET Standard 2.0 which means it runs on both .NET Framework >= 4.6.1 and .NET Core >=2.0, Mono, Xamarin, UWP.
Speedment is an exciting new startup in the java world leveraging in-memory in a way similar to OrigoDB. This article explains the Speedment concept and how it relates to OrigoDB.
Optimistic concurrency is a strategy for dealing with conflicting writes to a database. The example often used is when two users update the same piece of information at the same time. If no strategy is in place to deal with this situation, information can go lost. This is referred to as "Last write wins". A pessimistic strategy would be to first obtain a lock on the piece of information to be updated. This ensures no one else can save until we have released the lock. Finally, an optimistic strategy involves validating that the piece of information hasn't been modified by a different user and hoping for the best. If it has been modified, the operation is canceled and we have to somehow resolve the conflict. One simple way to detect conflicts is to compare the initial state of an entity with it's current state in the database.
Extending OrigoDB with some kind of scripting feature is something we have been thinking about for a long time. An obvious application would be the OrigoDB server console which now only understands 'exit'. Imagine the power of an interactive shell within the server process itself. So, I decided to play around with scriptcs to see what I could come up with.
Whoa! Our first runtime performance issue with OrigoDB. To populate geekstream we run a background process which periodically checks a number of RSS feeds. The feeds are added manually, either individually or from opml file. Initially, I was eager to pull in a lot of content quickly. I was able to achieve this by gobbling some opml files found with google, the bigger the better. This resulted in some quality issues
Do you remember the days when file formats had to be hand crafted not to mention all </span>the code needed to read and write them? Or even more cumbersome, implementing a network communication protocol? In some cases you probably still need to but fortunately there is a simpler way. Most platforms support reading and writing objects to a stream, file or string taking care of all the gory details for you. I first discovered object serialization when learning Java. I was immediately impressed by the power and simplicity. Days of work could now be done in seconds using a few lines of code.
System prevalence has a lot in common with event sourcing and cqrs. I'm not sure about how aware the two communities are of each other so I posted the following to the ddd/cqrs google group.
Here is some technical data about the LiveDB database backing the Geekstream search engine. The data was collected on 2012-08-21. Geekstream runs on a virtual win2008 standard server with 2GB of RAM assigned. The web application has a pool of stateful tcp/ip connections to the LiveDB server running on the same virtual machine. Also, an XSockets server is running to handle websocket connections for the LiveSearch feature.
Welcome to part 2 of this series. In [part 1](), we set up a very simple model containing a Dictionary of Page objects. In this article we will extend the model to handle hierarchical menus. A complete VS2010 solution is available for download below. Let’s start by having a closer look at the requirements specifically related to menus.
This is the first article in a series aiming to provide more detail of liveDB development than the auick start guide does. You can hack along or sit back and enjoy the ride and download the zipped VS2010 project later.
A prevalence engine supports two types of transactions, commands and queries. This is a very simple and flexible generalization which can be utilized for persistence using several different approaches. One way is to define a domain-specific business model together with a set of commands, for example PlaceOrderCommand, ChangeCustomerAdressCommand and so on. This approach works very well with object-oriented domain modeling. One major benefit is that no mapping is required between the object-oriented model and a separate database model. The in-memory object-oriented model IS the database.
ORIGO