3 ms·

Interesting. Without knowing what kind of system you're talking about I'm suspicious that I'd use this. I certainly have distributed problems like this where a

Interesting. Without knowing what kind of system you're talking about I'm suspicious that I'd use this. I certainly have distributed problems like this where a logical concept is broken into a number of steps, and while I want to distribute the steps.. the effects of them to the entire system might not be realized until all of them are complete. I generally wouldn't defer that responsibility to the database though. I'd more often handle this as multiple database transactions that advance a state machine, at the end of which consequence-inducing-events are fired off. The idea that process A tickles the database into some state expected to be understood (and only seen by) process B seems like too flimsy a contract to me.

_sh 15y ago
I get your point, but there is value in delegating to the database--how do I roll back an external state machine?
- bad_user 15y ago
  See the command pattern: http://en.wikipedia.org/wiki/Command_pattern http://en.wikipedia.org/wiki/Command_pattern Basically you encapsulate whatever you need to do with the database in objects (logic + parameters). And you describe for these objects not only the logic for updating the database (forward), but also for reverting the database to its previous state (rollback).
  - _sh 14y ago
    Yep, I know the command pattern--it requires knowledge of all state up front and breaks down in the presence of distributed state. It makes statements like 'update all records where value x is y' difficult. You need to gather all such records first, possibly guarding their current state with a timestamp/vector clock (we are talking distributed systems after all), make the change encapsulating the current state in the command pattern and commit. If you have to extend this model to multiple queries, you'll be rolling your own transaction protocol lest you expose partial state to other queries in transit. Or you could delegate all this to the database, which already has its own transaction protocol.

_sh 15y ago

I get your point, but there is value in delegating to the database--how do I roll back an external state machine?

bad_user 15y ago
See the command pattern: http://en.wikipedia.org/wiki/Command_pattern http://en.wikipedia.org/wiki/Command_pattern Basically you encapsulate whatever you need to do with the database in objects (logic + parameters). And you describe for these objects not only the logic for updating the database (forward), but also for reverting the database to its previous state (rollback).
- _sh 14y ago
  Yep, I know the command pattern--it requires knowledge of all state up front and breaks down in the presence of distributed state. It makes statements like 'update all records where value x is y' difficult. You need to gather all such records first, possibly guarding their current state with a timestamp/vector clock (we are talking distributed systems after all), make the change encapsulating the current state in the command pattern and commit. If you have to extend this model to multiple queries, you'll be rolling your own transaction protocol lest you expose partial state to other queries in transit. Or you could delegate all this to the database, which already has its own transaction protocol.