ANYLOGIC AGENT THREAD CODE
I am hoping to use an existing library for a global process registry, the client side will have to identify itself through an ID, and the server side code will identify the process through that ID in that registry, so you are right, it is extra code. I actually can be the birth of a new framework, why not? But maybe, it would be a good idea to make a PoC of it. I am thinking since each user is a process, the users can communicate among themselves using message passing as well.Īgain, more code for you. The “states between user” part is interesting, I didn’t think of that. I mean, it’s not a bad idea, I am just showing the trade-off’s, and maybe, for some applications, this is actually the best way to do it. This can be very complex, and using a db you get it done quickly. Still, if it’s a feature that one user can affect the other user state, you’ll have to make your own code to manage one user (process) updating the other user data. Thanks for the reply all very good points, I will try to build on some of them. I am not very experienced with Elixir, please share what you think, am I missing something that will prevent this from working well?
To solve those issues, we often resolve to adding database constraints, unfortunately any logic that we put in the database layer is not unit testable or easily understandable. If combined with a stateless frontend + server side, you can get into race conditions: the husband trying to checkout on the website, but the wife is deleting the same cart on the mobile app customer tries to add the same product on both web and mobile at the same time, but the business rule is that 1 custom can only buy 1. On top of that you need to make sure you have some thread safe data structure on the server side that can load/save the user state.ĭatabase state, stateless server/client side: the most used case, unfortunately also the slowest one because in most cases it means a network hop. You can kind of solve it by sophisticated routing based on cookie/request param to make sure the same user (even with different devices) always end up on the same server. Server side state: this is very problematic in a clustered environment, you might end up with multiple states on different servers that all represent the same user.
To synchronize them is difficult, and I’d say any technique can only shrink the window where the race condition happen instead of preventing it. In my past experience with web applications in other languages, there are really 3 ways to manage state:Ĭlient side state: basically the entire state is passed from front to back in every request, the problem with this is if I have a web front end and a mobile front end, they will end up overwriting each other. I think the reason why people choose stateless because there is no good technology stack that allows them to do stateful safely. In my opinion, stateful applications are a lot easier to reason about than a “stateless” application, I am putting “stateless” in quotes because I haven’t really seen a useful application that doesn’t have any side effects/states. I am looking for people to enlighten me to agree/disagree with my thinking. Recently I’ve been thinking about how Elixir can help me manage state in a distributed web application. The concurrency model of Elixir is really fascinating, along side immutability, they are my favourite things about Elixir.
0 kommentar(er)
