4 ms·

> I'd argue this is a double barreled footgun as most usage of MongoDB is from garbage collected languages. One wrongly time GC and your transaction is dead. T

by mayank 8y ago

> I'd argue this is a double barreled footgun as most usage of MongoDB is from garbage collected languages. One wrongly time GC and your transaction is dead. That’s not how it works. The transaction as a whole is sent to Mongo for execution server side; the client isn’t manually controlling transaction execution.

koolba 8y ago
> That’s not how it works. In the example on the docs page it looks like the logic is happening in the app code: https://docs.mongodb.com/master/core/transactions/#retry-transaction-and-commit-operation https://docs.mongodb.com/master/core/transactions/#retry-tra... Granted it's only writing to some collections but I assumed you can read from the session during a transaction. > The transaction as a whole is sent to Mongo for execution server side; the client isn’t manually controlling transaction execution. Are you saying that transactions are serialized as a series of pure updates and sent to the server as such? i.e you can't read a value, use it for some logic, update some other values, repeat ..., then commit? If that's the case this would be better labeled as "Multi-document atomic updates" as (to me) transaction implies interaction with the data in app code.
- mayank 8y ago
  > In the example on the docs page it looks like the logic is happening in the app code Not quite. The code in the docs you linked to handle what happens when a transaction does not complete server-side -- typically, you want to re-try the entire transaction a few times in case transient locks have been released or preconditions met. It does not suggest that the transaction is being controlled/orchestrated by the client. > Are you saying that transactions are serialized as a series of pure updates and sent to the server as such? Yes, generally. Check out examples of Postgres transactions -- they are plain-text "queries" that are executed with all-or-nothing semantics. > (to me) transaction implies interaction with the data in app code. Transactions, generally, are groups of statements/queries that are either all applied or none at all. They do not imply interaction with the data in app code, unless the app code itself is executed as part of the transaction itself (e.g., UDFs or stored procedures). They are like mini-programs that are shipped to the DB to be executed in a concurrency controlled and undo-able environment.

by mayank 8y ago

koolba 8y ago

> That’s not how it works. In the example on the docs page it looks like the logic is happening in the app code: https://docs.mongodb.com/master/core/transactions/#retry-transaction-and-commit-operation https://docs.mongodb.com/master/core/transactions/#retry-tra... Granted it's only writing to some collections but I assumed you can read from the session during a transaction. > The transaction as a whole is sent to Mongo for execution server side; the client isn’t manually controlling transaction execution. Are you saying that transactions are serialized as a series of pure updates and sent to the server as such? i.e you can't read a value, use it for some logic, update some other values, repeat ..., then commit? If that's the case this would be better labeled as "Multi-document atomic updates" as (to me) transaction implies interaction with the data in app code.

mayank 8y ago
> In the example on the docs page it looks like the logic is happening in the app code Not quite. The code in the docs you linked to handle what happens when a transaction does not complete server-side -- typically, you want to re-try the entire transaction a few times in case transient locks have been released or preconditions met. It does not suggest that the transaction is being controlled/orchestrated by the client. > Are you saying that transactions are serialized as a series of pure updates and sent to the server as such? Yes, generally. Check out examples of Postgres transactions -- they are plain-text "queries" that are executed with all-or-nothing semantics. > (to me) transaction implies interaction with the data in app code. Transactions, generally, are groups of statements/queries that are either all applied or none at all. They do not imply interaction with the data in app code, unless the app code itself is executed as part of the transaction itself (e.g., UDFs or stored procedures). They are like mini-programs that are shipped to the DB to be executed in a concurrency controlled and undo-able environment.