Optimistic concurrency is not performant when dealing with highly-contested objects or storage. I wish copy-on-write, deltas (like git), and event driven had been discussed. Locking VS nonlocking approaches have tradeoffs. The tradeoffs need to b be discussed here.
Sure, contention plays a roll in deciding which strategy to use. Optimistic concurrency doesn't necessarily falter in high contention situations. You're often wanting to confirm that the action taken by an end user was using current data so they can make an informed decision. Meaning you want them to have the latest information to be informed about the action they are taking. That means you can use different strategies like keeping the client informed of various updates so they can still perform the required action. Also when we're getting out of CRUD and its often capability centric this can change as well as the data users are looking at are often a composition of data.
@@CodeOpinion yeah, I'm thinking about down stream or automated operations where you might see 10 to 20k transactions per second. OC is fine for most human editing forms scenarios, but versions deltas is even better.
When using somthing like event sourcing, couldn't you potentially make available any version of a piece of data we want, we just play forward from some recent snapshot and return that version.
With EventStore for example, you can use optimistic concurrency, as it's built-in. When you append events to your event-stream, you can tell it where you expect the event stream to be (eg, what position. Your snapshot generally points to where in the event stream it was taken.
it's an implementation of the Actor Model. But the same idea can be realized in various ways, for example having a queue that groups messages such that all messages in a group are handled, in order, by a single consumer; such message group is sometimes called partition. When you have a lot of writes for an optimistically locked entity (hello Aggregate Root) you'll need this kind of pattern most definitely.
None of this would be a problem if we just took a step back and rethought our problem solving approach. Why are we accepting all of this accidental complexity in the first place? So we can keep using our beloved programming language? The web is highly concurrent, however none of our mainstream idioms have a clear-cut way of solving this issue. The actor model solves the concurrency problem from the get-go and makes it a piece of cake to deal with it. If you *really* want to solve the concurrency problem, properly, The BEAM is your friend.
What the video shows is not accidental complexity at all, sometimes you don't need a full blown Actor Model framework, I can't even see how to solve the reservation pattern using only actors, you need temporal decoupling. And for the BEAM, it is not distributed, so you loose scalability.
@@arielmoraes9427 I think you're wrong about the scalability (or I'm misinterpreting), key feature of BEAM is support for distributed cluster of nodes. The only problem with Elixir/Erlang, for me, is that these are dynamically typed languages ;(
Contrary to what is sometimes claimed, the Actor model is not the solution for most Enterprise applications. We have extensively investigated MS Orleans and tried to solve various scenarios. The hard conclusion was that the MS Orleans or Actor model in general shines in scenarios where an object/entity of your system needs to be activated for a long time. That's why you see it often used in online gaming, because a 'player' is loaded and then all kinds of data about a player is changed while gaming. The single thread concept helps in multi-player games and to prevent items traded between users be lost, for example. Those kind of actions would be handled in an ACID manner between the players. Moreover, the most suitable database for these types of programs is a No-SQL database. But in all other cases where an entity/object is loaded briefly to display something or make a change to the database like CRMs and Web Shops,, there is little to no benefit to using an Actor model. In most cases having a Relational data often indicates that you should stay away from the Actor model. I can write a few pages about our findings including performance, scalability, maintenance, failures, recovery, deployment, etc... but the fact that there is so little adoption for the Actor model should ring a bell ;-)
Learn more about Software Architecture & Design by subscribing to my newsletter.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
one of the great channels i have started following! thank you!!
Welcome!
Hi Derek, you promised to put a link in the description, but I can't find it, it could be me though:)
Virtual Actor with Microsoft Orleans: th-cam.com/video/iE8cisVgoj8/w-d-xo.html
The other two referenced are linked at the end of the video.
Optimistic concurrency is not performant when dealing with highly-contested objects or storage.
I wish copy-on-write, deltas (like git), and event driven had been discussed. Locking VS nonlocking approaches have tradeoffs. The tradeoffs need to b be discussed here.
Sure, contention plays a roll in deciding which strategy to use. Optimistic concurrency doesn't necessarily falter in high contention situations. You're often wanting to confirm that the action taken by an end user was using current data so they can make an informed decision. Meaning you want them to have the latest information to be informed about the action they are taking. That means you can use different strategies like keeping the client informed of various updates so they can still perform the required action. Also when we're getting out of CRUD and its often capability centric this can change as well as the data users are looking at are often a composition of data.
@@CodeOpinion yeah, I'm thinking about down stream or automated operations where you might see 10 to 20k transactions per second. OC is fine for most human editing forms scenarios, but versions deltas is even better.
When using somthing like event sourcing, couldn't you potentially make available any version of a piece of data we want, we just play forward from some recent snapshot and return that version.
With EventStore for example, you can use optimistic concurrency, as it's built-in. When you append events to your event-stream, you can tell it where you expect the event stream to be (eg, what position. Your snapshot generally points to where in the event stream it was taken.
This is really the first time I heard the distributed single thread approach. Anybody actually do this in production ?
it's an implementation of the Actor Model. But the same idea can be realized in various ways, for example having a queue that groups messages such that all messages in a group are handled, in order, by a single consumer; such message group is sometimes called partition. When you have a lot of writes for an optimistically locked entity (hello Aggregate Root) you'll need this kind of pattern most definitely.
Distributed lock is the way to restrict to single thread.
@@Foodies-pv7ih does distributed lock implied some kind of heartbeating to avoid dangling lock ?
@@sakesun is all upto you, how you are implementing, or if you are using 3rd party providers
@@sakesunusually it's TTL. If the lock is not released after some time, it is done by TTL expiration
Derek, do you think AI will take away the jobs of programmers in the next 2 years?
I just did a video about this. th-cam.com/video/7DU51BN4UAs/w-d-xo.html
None of this would be a problem if we just took a step back and rethought our problem solving approach.
Why are we accepting all of this accidental complexity in the first place? So we can keep using our beloved programming language?
The web is highly concurrent, however none of our mainstream idioms have a clear-cut way of solving this issue. The actor model solves the concurrency problem from the get-go and makes it a piece of cake to deal with it.
If you *really* want to solve the concurrency problem, properly, The BEAM is your friend.
Erlang?
What the video shows is not accidental complexity at all, sometimes you don't need a full blown Actor Model framework, I can't even see how to solve the reservation pattern using only actors, you need temporal decoupling. And for the BEAM, it is not distributed, so you loose scalability.
@@arielmoraes9427 I think you're wrong about the scalability (or I'm misinterpreting), key feature of BEAM is support for distributed cluster of nodes. The only problem with Elixir/Erlang, for me, is that these are dynamically typed languages ;(
Contrary to what is sometimes claimed, the Actor model is not the solution for most Enterprise applications. We have extensively investigated MS Orleans and tried to solve various scenarios. The hard conclusion was that the MS Orleans or Actor model in general shines in scenarios where an object/entity of your system needs to be activated for a long time. That's why you see it often used in online gaming, because a 'player' is loaded and then all kinds of data about a player is changed while gaming. The single thread concept helps in multi-player games and to prevent items traded between users be lost, for example. Those kind of actions would be handled in an ACID manner between the players. Moreover, the most suitable database for these types of programs is a No-SQL database. But in all other cases where an entity/object is loaded briefly to display something or make a change to the database like CRMs and Web Shops,, there is little to no benefit to using an Actor model. In most cases having a Relational data often indicates that you should stay away from the Actor model. I can write a few pages about our findings including performance, scalability, maintenance, failures, recovery, deployment, etc... but the fact that there is so little adoption for the Actor model should ring a bell ;-)