4 ms·

Following through the blog to the actual docs: https://docs.mongodb.com/master/release-notes/4.0/ https://docs.mongodb.com/master/release-notes/4.0/ > By defau

by koolba 8y ago

Following through the blog to the actual docs: https://docs.mongodb.com/master/release-notes/4.0/ https://docs.mongodb.com/master/release-notes/4.0/ > By default, multi-document transactions wait 5 milliseconds to acquire locks required by the operations in the transaction. If the transaction cannot acquire its required locks with the 5 milliseconds, the transaction aborts. Automatic cancellation rather than actual deadlock detection is going to be one hell of a footgun. 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.

xeromal 8y ago
What's a footgun? Is that a play on shooting yourself in the foot? :P
- breser 8y ago
  Generally a footgun is something that's designed in such a way as to be extremely likely to be used in a way that's going to cause problems for yourself. Yes it's a play on shooting yourself in the foot, the idea is that you designed a gun designed to shoot yourself in the foot. https://www.urbandictionary.com/define.php?term=footgun https://www.urbandictionary.com/define.php?term=footgun
  - hinkley 8y ago
    It's talking about shooting yourself in the foot, but doesn't blame the victim. For me, it's one of the better cultural changes in software development in the last five years.
bpicolo 8y ago
> One wrongly time GC and your transaction is dead Are the locks not database-side, rather than client-side?
- cyberfart 8y ago
  Yes, locks are server-side.
angersock 8y ago
> Automatic cancellation rather than actual deadlock detection is going to be one hell of a footgun. Well, this would be in keeping with MongoDB's track record, sooooo
- Analemma_ 8y ago
  Without silently dropping transactions, how could it ever be web scale?
  - syn_rst 8y ago
    It doesn't get more web-scale than `/dev/null`. Unlimited throughout, zero latency, full availability and consistency even in the presence of partitions, and constant network usage for any number of nodes! There's a chance of data loss, of course, but the write performance is so good that it's a perfect fit for workloads like analytics or logging.
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 koolba 8y ago

xeromal 8y ago

What's a footgun? Is that a play on shooting yourself in the foot? :P

breser 8y ago
Generally a footgun is something that's designed in such a way as to be extremely likely to be used in a way that's going to cause problems for yourself. Yes it's a play on shooting yourself in the foot, the idea is that you designed a gun designed to shoot yourself in the foot. https://www.urbandictionary.com/define.php?term=footgun https://www.urbandictionary.com/define.php?term=footgun
- hinkley 8y ago
  It's talking about shooting yourself in the foot, but doesn't blame the victim. For me, it's one of the better cultural changes in software development in the last five years.

bpicolo 8y ago

> One wrongly time GC and your transaction is dead Are the locks not database-side, rather than client-side?

cyberfart 8y ago
Yes, locks are server-side.

angersock 8y ago

> Automatic cancellation rather than actual deadlock detection is going to be one hell of a footgun. Well, this would be in keeping with MongoDB's track record, sooooo

Analemma_ 8y ago
Without silently dropping transactions, how could it ever be web scale?
- syn_rst 8y ago
  It doesn't get more web-scale than `/dev/null`. Unlimited throughout, zero latency, full availability and consistency even in the presence of partitions, and constant network usage for any number of nodes! There's a chance of data loss, of course, but the write performance is so good that it's a perfect fit for workloads like analytics or logging.

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.