By default, a Transaction has an IsolationLevel of Serializable. Serializable is the highest level. It requires that the transaction completes before any other transaction is allowed to operate on the data. It has the following restrictions: Statements cannot read data that has been modified but not yet committed by other transactions. No other transactions can … Read more
I would first differentiate between optimistic and pessimistic locks, because they are different in their underlying mechanism. Optimistic locking is fully controlled by JPA and only requires additional version column in DB tables. It is completely independent of underlying DB engine used to store relational data. On the other hand, pessimistic locking uses locking mechanism … Read more
Postgres does support nested transactions, but they differ from the conventional SQL, more like transactions with nested partial points. On the top level you always have your typical BEGIN/COMMIT/ROLLBACK, and on nested levels you have to use the following commands: SAVEPOINT name – creates a new savepoint, with name unique for the transaction RELEASE SAVEPOINT … Read more
Yet another simpler way with some extra fundrawtransaction. Docs say us what inputs and output all required fields. But don’t forget empty list is object too: Step 1) $ bitcoin-cli createrawtransaction ‘[]’ \ ‘{“mxh3H416KCRoBDiweSESew5YJyAk1nxLrN”: 0.025}’ Step 2) $ bitcoin-cli fundrawtransaction <hex_createrawtransaction> \ ‘{“changeAddress”: “mkrzDhhZtzQm8zgckSs4fMNrvtNJ66zaFe”}’ After second step you can look at the fee generated by … Read more
The best way to distribute transactions over more than one database is: Don’t. Some people will point you to XA but XA (or Two Phase Commit) is a lie (or marketese). Imagine: After the first phase have told the XA manager that it can send the final commit, the network connection to one of the … Read more
There is an overload of the ExecuteSqlCommand method that prevents this behavior: db.Database.ExecuteSqlCommand(TransactionalBehavior.DoNotEnsureTransaction, sql, parameters);
I know it’s kind of late answer but i found it useful to share. Now in EF6 it’s easier to achieve this by using dbContext.Database.BeginTransaction() like this : using (var context = new BloggingContext()) { using (var dbContextTransaction = context.Database.BeginTransaction()) { try { // do your changes context.SaveChanges(); // do another changes context.SaveChanges(); dbContextTransaction.Commit(); } … Read more
The javadoc for JpaTransactionManager has some advice on this: This transaction manager is appropriate for applications that use a single JPA EntityManagerFactory for transactional data access. JTA (usually through JtaTransactionManager) is necessary for accessing multiple transactional resources within the same transaction. Note that you need to configure your JPA provider accordingly in order to make … Read more
You’re right: at the standard isolation level, read committed, you do not need to wrap select statements in transactions. Select statements will be protected from dirty reads whether you wrap them in a transaction or not. connection 1: connection 2: begin transaction update user set name=”Bill” where id = 1 select name from users where … Read more
Here is some pseudo-code with nested transaction blocks and database operations X, Y, and Z: with transaction.atomic(): X with transaction.atomic(): Y Z If X raises an exception then obviously none of the operations will get the chance to commit in the first place. If Y raises an exception—which was the question you referenced—then the outer … Read more