Lock distribution transaction in oracle database
I have a question about blocking transactions in an oracle database. So far I have found that:
Reason . A distributed transaction has timed out a lock timeout. This time is specified in the initialization parameter DISTRIBUTED_LOCK_TIMEOUT
.
Action . This situation is viewed as a dead end and the assertion has been dropped. To set the timeout interval to a longer interval, adjust the initialization parameter DISTRIBUTED_LOCK_TIMEOUT
, then shutdown and restart the instance.
Some other things I want to know in more detail are things like:
-
It is mentioned that there was a lock in a "distributed transaction". So what database operation can cause this? Updating a record? Record selection?
-
Which means "Distributed" anyway. I've seen this term coined all over the place, but I can't imagine what it means.
-
What can we do to reduce the instances of such a lock?
source to share
A distributed transaction means that you had a transaction with two different participants. If you are using PL / SQL, this usually means having multiple databases. But this may simply indicate that the application is using an external transaction coordinator in conjunction with the database. For example, a J2EE application might want to create a distributed transaction that spans both the release of SQL statements and the database to move $ 100 from account A to account B, and the application server action to create a JMS message for that transaction which will eventually trigger an email notification of the transfer to be sent. In this case, the application wants to make sure the mid-level state matches the back end state.
Distributed transactions are not free. They involve potentially quite a lot of additional overhead, since at a minimum, you need to use a two-phase commit protocol to ensure that all the components that go into a distributed transaction are ready to commit and to verify that they all have committed. This is due to the sending of multiple network packets, which can be a significant portion of the OLTP transaction timeout. Distributed transactions also cause administrative problems, as you end up with cases where the transaction of one participant fails after it indicated that it is ready to commit, or the coordinator of the transaction failed to complete while different participants have open transactions.
So, the first question will be whether your application really requires distributed transactions. Sometimes developers find that they accidentally request distributed transactions when they are not really needed. If you don't know what a distributed transaction is, it is possible that you don't really need them.
source to share