My original, and higher-level issue here was that my server has only got a certain amount of resources (let’s say it’s about 20 to 30 connection width in terms of concurrency).
My save function is actually a lot more complicated than the simple example I’ve been discussing here. My save function saves depth-first, and saves an entire graph (a tree) of objects, including incidental associated objects.
What I actually want is a way to tell ember-data the maximum concurrency of the server… and to have it respect that, and build and evaluate a queue… interestingly this is a similar problem domain to the one that the ember runloop deals with in the UI level - how to schedule, reschedule and run various set of instructions that have impact on a stateful environment.
And even then, at a certain point, even with some awareness of concurrency… this is just one single client we’re ever talking about… It’s quite possible that 200 users might all be trying to save an entire tree of records at the same time… in which case I’d like some of them to wait, and retry… up to a certain amount of time (say 10 seconds) after which it should inform the user and ask them what they’d like to do, or possibly just retry later… (in 30 seconds a few times or something).
This stuff, though, is kind of the province of the framework, not the application… it’s a feature of the data persistence layer, or at least should be. I shouldn’t be writing custom save code that manages concurrency, especially when it’s possible that the server and client framework really should be communicating about what’s possible.
(Point in case… sometimes the server might have capacity to handle 200 width concurrency connections, other times it might have only the capacity for 4 concurrent connections per client… this should depend on the load on the server, the resources available to the server, and a whole bunch of other things, but really it should be dynamic, not static, and definitely not application-level programmed).
Interesting. Food for thought. In the meantime, I’m going to go mitigate my issues in the application layer… because that’s where I’m seeing my symptoms, but I’m quite aware that I’m only putting a bandaid over a problem that will rear its head quite soon again.