This example is the same as nodejs/sequelize/raw/parallel_select_and_update.js, but going through Sequelize rather than with Sequelize raw queries. NONE is not supported for now to not have a transaction at all because lazy.

Sample invocation:

node --unhandled-rejections=strict ./parallel_select_and_update.js p 10 100 READ_COMMITTED UPDATE

where:

READ_COMMITTED: one of the keys documented at: sequelize.org/master/class/lib/transaction.js~Transaction.html which correspond to the standard sQL isolation levels. It not given, don't set one, defaulting to the database's/sequelize's default level.
UPDATE: one of the keys documented at: sequelize.org/master/class/lib/transaction.js~Transaction.html#static-get-LOCK. Update generates a SELECT FOR UPDATE in PostgreSQL for example. If not given, don't use any FOR xxx explicit locking.

Other examples:

node --unhandled-rejections=strict ./parallel_select_and_update.js p 10 100 READ_COMMITTED UPDATE

READ_COMMITTED: fails
READ_COMMITTED UPDATE: works
REPEATABLE_READ: works, but is a bit slower, as it does rollbacks
This case also illustrates Sequelize transaction retries, since in this transaction isolation level transactions may fail:

 Ancestors (14)

 Discussion (0)

There are no discussions about this article yet.

There are currently no matching articles.