3 ms·

How would the API ensure this when getting passed a transaction? I fail to understand this. A transaction has two main methods, commit and rollback (do I miss s

by chopin 9y ago

How would the API ensure this when getting passed a transaction? I fail to understand this. A transaction has two main methods, commit and rollback (do I miss some?). I'd never want an API to call those. That's up to the caller.

amelius 9y ago
When you manipulate the state of something (e.g. database or memory), then in a transactional system you have to specify in which transaction the change is supposed to occur. So besides commit and rollback, a transaction has a "change" method, if you'd like to look at it that way. The change method is what makes transactions useful. And the API function is indeed supposed to call only "change", not "commit" or "rollback".
- chopin 9y ago
  https://docs.oracle.com/javaee/6/api/javax/persistence/EntityTransaction.html https://docs.oracle.com/javaee/6/api/javax/persistence/Entit... doesn't have this. Could you point to a transaction (preferably in Java) which permits a "change"?
  - sk5t 9y ago
    I am also baffled as to what this "change" operation is meant to suggest. Enlisting possibly-unrelated operations in a common transaction is a good tool to have in the toolbox, although it is a tad hairy to bake that into each method signature. Spring's TransactionTemplate presents an alternate approach.
jeffreyrogers 9y ago
I think the person you're replying to means something like "context" rather than what you're calling a transaction. So you'd give the function all the context it needs to atomically perform whatever update it needs to perform. That's my best guess at least. Of course, part of the reason we don't do this is performance: it costs a lot to copy around all the state you need to perform an action.
- amelius 9y ago
  You can call it a transaction context, but it's really a transaction that's being passed, i.e., you're saying to the called function: every change you make is happening within this transaction I'm passing you here. It's nothing new of course. What I'm saying here is that APIs should support the concept.

by chopin 9y ago

amelius 9y ago

When you manipulate the state of something (e.g. database or memory), then in a transactional system you have to specify in which transaction the change is supposed to occur. So besides commit and rollback, a transaction has a "change" method, if you'd like to look at it that way. The change method is what makes transactions useful. And the API function is indeed supposed to call only "change", not "commit" or "rollback".

chopin 9y ago
https://docs.oracle.com/javaee/6/api/javax/persistence/EntityTransaction.html https://docs.oracle.com/javaee/6/api/javax/persistence/Entit... doesn't have this. Could you point to a transaction (preferably in Java) which permits a "change"?
- sk5t 9y ago
  I am also baffled as to what this "change" operation is meant to suggest. Enlisting possibly-unrelated operations in a common transaction is a good tool to have in the toolbox, although it is a tad hairy to bake that into each method signature. Spring's TransactionTemplate presents an alternate approach.

jeffreyrogers 9y ago

I think the person you're replying to means something like "context" rather than what you're calling a transaction. So you'd give the function all the context it needs to atomically perform whatever update it needs to perform. That's my best guess at least. Of course, part of the reason we don't do this is performance: it costs a lot to copy around all the state you need to perform an action.

amelius 9y ago
You can call it a transaction context, but it's really a transaction that's being passed, i.e., you're saying to the called function: every change you make is happening within this transaction I'm passing you here. It's nothing new of course. What I'm saying here is that APIs should support the concept.