>The concept of 'transaction' doesn't really make sense in this approach, since I'm directly modifying the data in memory, every change I make is atomic and can't fail, and I flush the data to the disk atomically as well.

So you don't have mutable data shared between threads then?

> So you don't have mutable data shared between threads then?

I might have worded that one sentence a little better, sorry.

I do technically need to share data between threads, since my event loop runs on multiple threads, so if I want to mutably modify something I do need to wrap it either in a `Mutex` or an `RwLock` and lock it.

What I meant was that it is not the same as a "transaction" in the SQL sense. It can't fail, there is no rollback, I decide on my own what level of granularity I need, and I bake the necessary atomicity into the data structures itself. So there are no SQL-style transactions anywhere - I just use a lock where it's appropriate to directly modify the memory, just as you'd do in any other situation. (Either by wrapping the whole structure in a lock, or wrapping only a single field, or by simply making the field atomic by itself.)

So it's a simple mmap database like early versions of MongoDB? I like using atomic commands, but I imagine it would become tedious fast to do the extra work of doing the accounting of the transaction manually every time you want to do a non atomic transaction.

> So it's a simple mmap database like early versions of MongoDB?

Even simpler. I use mmap only for things that I build offline and that never change during the runtime. Everything else is just kept as your garden variety objects in memory.

(Well, although I guess you could say it is an mmap database, it's just that the mmaped file is the swap, and the OS manages it for me.)

> I like using atomic commands, but I imagine it would become tedious fast to do the extra work of doing the accounting of the transaction manually every time you want to do a non atomic transaction.

In my case it's not really tedious at all. Usually when I want to mutate something it looks something like this:

    let user_ref = state.require_login()?;
    let user = user_ref.write();
    user.set_field(value);
    drop(user);

Of course this depends on your requirements. If you'd have 20 different objects of 10 different types that you'd have to lock separately and you'd want to update all of them atomically it might become hairy (SQL would definitely be better in such a case), but I don't have such cases.

I do similar stuff to what you do, writing my backend code in Rust and not using a database but opting instead to keep things in memory and flushing to disk on my own. And running servers that I manage with SSH.

I would love to talk with you and exchange knowledge. Your HN profile has no publicly visible contact info though.

Do you have an email address I can reach you on? Can you put it in your HN profile description?

Sure. You can email me at j@exia.io.

(Just please note that if I apparently don't reply and if you're using gmail then my reply probably went to spam or gmail's /dev/null, so email me again; lately gmail doesn't like emails that I send and either puts them into spam or just sends them to /dev/null, even when I'm replying to someone that emailed me first! So much for Google having no monopoly, sigh...)

I run my own mail server so there’s also a chance that I end up in your spam folder instead when I send you a mail, if you do spam filtering :p

The basic stuff Rust will solve for you, but it is easy to forget logical dependencies and get an inconsistent state anyways... Just the ordinary close a session, send error message if not alive has bitten us in a 20 person project.