3 ms·

Could you give an example under which circumstances you'd want this? The last thing I'd want to give an API is such an object in order to do something for me (

by chopin 9y ago

Could you give an example under which circumstances you'd want this? The last thing I'd want to give an API is such an object in order to do something for me (like committing). I'd had more than one occasion where I had to pass an InputStream to an API only to find out that it kindly closed it for me. This is unfortunate if you want to pass a ZipInputStream: as it does not hand out separate streams for entries, closing the stream does close the entire stream, not the entry passed.

amelius 9y ago
> The last thing I'd want to give an API is such an object in order to do something for me (like committing). That's not what the transaction is supposed to be passed for. It's simply passed as a way to ensure that state changes are atomic. Basically, if you're using transactions inside a program, passing them between functions, that's the same concept. Except now you're passing the transaction to an API.
- 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

> The last thing I'd want to give an API is such an object in order to do something for me (like committing). That's not what the transaction is supposed to be passed for. It's simply passed as a way to ensure that state changes are atomic. Basically, if you're using transactions inside a program, passing them between functions, that's the same concept. Except now you're passing the transaction to an API.

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.