When shutting down my project's WebSphere-based JavaEE application, distributed transactions are sometimes left alive in the SQLServer 2005 database. These retain their locks forever and must be killed manually. They are described generally in this very good article.
The article talks about how the transaction coordinator is unable to co-ordinate the distributed transaction participants and so flags the transaction with a process ID of -2.
Given that we get this issue infrequently, but that it always happens when we shut down the application, I am not convinced it is a failure of the MSDTC. It is more likely to have something to do with WebSphere and how it terminates applications.
I would like to test it. But I cannot reliably make it happen.
Is there any way to force the MSDTC to orphan a SQLServer distributed transaction?
My question was misleading, because I wasn't quite sure what the problem actually was. I suspect MSDTC is assisting WebSphere in transacting with MQ and SQLServer. The problem occurs when we perform an unclean shutdown of the WAS server and the vendor-provided part of our application tries to do some sort of cleanup and fails.
I suspect this question is not helpful to anyone else (unless they are using the Misys Message Manager in WebSphere on Windows) so apologies, dear reader, for wasting your time.
Orphaned DTC transactions can occur in case SQLServer sessions with open but not yet prepared DTC or XA transactions are closed. This may happen because of network interruption or due to unexpected application abort.
In this case SQLServer keeps the transaction with DTC and the SPID is -2.
The post on SQLServerCentral mentions that following query can be used to identify the orphaned transactions:
Select req_transactionUOW
from master..syslockinfo
where req_spid = -2
Exeuting "kill" with the UOW given as argument, will remove the active ransaction.
This behavior of SQLSever is very uncommon. Usually a session loss will abort any XA transaction.
The good news is that SQLServer provides an option that changes this behavior.
The trace flag 3924 can be set in order to achieve this. Just exec DBCC TRACEON(3924,-1) with "sa" privileges and SQLServer automatically removes transactions in case sessions get lost.
The trace flag will be lost on SQLServer restart. In order to get it set during SQLServer startup automatically add it in SQLServer configuration manager:
SQLServer Configuration Manager sceenshot
Related
We have a situation where procedures with DML operations are often run by different users at different point in time, and I need to shutdown my database for recovery purpose.
So, I want to know what happens to the PL/SQL blocks (procedures with DML operations in this case) if shutdown immediate or shutdown transactional command is issued
In case of normal SQL command shutdown immediate will just rollback the DML operations and Shutdown transactional will wait for the transaction to complete, but what with PL/SQL blocks.
I have searched by not found answer to this question, every where reference to SQL command is only given.
You can find all you need, here.
Extract from page:
Shutting Down with the NORMAL Clause
To shut down a database in normal situations, use the SHUTDOWN command
with the NORMAL clause:
SHUTDOWN NORMAL
The NORMAL clause is optional, because this is the
default shutdown method if no clause is provided.
Normal database shutdown proceeds with the following conditions:
No new connections are allowed after the statement is issued.
Before the database is shut down, the database waits for all currently
connected users to disconnect from the database.
The next startup of the database will not require any instance
recovery procedures.
Shutting Down with the IMMEDIATE Clause
Use immediate database shutdown only in the following situations:
To initiate an automated and unattended backup
When a power shutdown is going to occur soon
When the database or one of its applications is functioning
irregularly and you cannot contact users to ask them to log off or
they are unable to log off
To shut down a database immediately, use the SHUTDOWN command with the
IMMEDIATE clause:
SHUTDOWN IMMEDIATE
While using websphere datasource to connect SQL-SERVER spring transaction getting hanged (Locked) with REQUIRES_NEW or NOT_SUPPORTED propogations.
This is not the case when using BasicDataSource or any other.
Please help.
REQUIRES_NEW and NOT_SUPPORTED are both transaction attributes that would prevent running the operation in the current transaction (which would be suspended and then resumed afterwards). The WebSphere Application Server data source is aware of container managed transactions and will enlist in them. I'm not sure what BasicDataSource is, but if it is not aware of container transactions, that could explain why you see a difference in behavior.
The flow to cause a single-thread deadlock could be something like this:
transaction begin
SQL command that locks row X
invoke REQUIRES_NEW method
implies transaction suspend, new transaction begin
SQL command that attempts to lock row X <-- deadlock here
If this is what you are seeing, it is operating as designed, per spec, and you should consider using a different transaction attribute, such as SUPPORTS, if you want the operation to run in the same transaction.
I've inherited an application that uses Atomikos for transaction handling in Spring on top of an Oracle database. In production deployments transaction logging has always been enabled by setting com.atomikos.icatch.enable_logging=true but the truth is I can't find any info on what exactly these logs are used for.
The atomikos site states "this should never be disabled on production or data integrity cannot be guaranteed" and I found a comment in a jta.properties on that site that said there is a "risk of losing data after restart or crash" if it is disabled.
We don't enable this in our development environments and are able to use the application normally. I thought they might be used in the case of the application crashing but if so I'm not sure how they'd be used. Maybe automatically during the next startup or manually in some way? In terms of data integrity I know Oracle enables it's own data recovery but maybe these transaction logs hold data that Oracle hasn't seen yet, e.g. if Spring were to crash.
http://fogbugz.atomikos.com/default.asp?community.6.1950.6 seems to indicate that the transaction logs are used for recovery only and can be disabled if you don't need them for recovery.
These logs maintain transaction information in the latest revision that may not be known yet to your database. without this set, recovery after a crash/restart will probably be incorrect.
HTH
Guy
Before I answer you question you need to read the begining of this post here How would you tune Distributed ( XA ) transaction for performance? to get the therminology.
The Atomikos is acting as Transaction coordinator who coordinates across the participants which are the different databases. As a coordinator it orchestrate the process of transactions accross the different databases. It is essentialy the same work that a Policemen is doing at the middle of a crossroad.
Atomikos writes its log file in order to know where exactyly in the process of the distributed transaction it is. In case of failure it can trace its uncommited transactions progress and attempt from the place it was previously interrupted. As such the transaction log is very important for the transaction recovery process.
I wonder a case. I have a project using a database (Oracle and Mssql). My project has a framework that I manage transactions.
In thread I open a database connection and start a transaction.(In transaction, there are many update and insert queries.) While code is running, somehow connection is closed. Because I have try-catch block, I catch exception and rollback transaction. BUT; if my connection is closed because some reasons, how rollback query can run on database? How can I handle this situation? If I open a new connection and rollback, does it work?
Thanks.
There is a term you should know - ACID compliancy:
Atomicity is an all-or-none proposition;
Consistency guarantees that a transaction never leaves your database in a half-finished state.
Isolation keeps transactions separated from each other until they’re finished.
Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination.
Concerning MySQL
In order to get this at MySQL, you have to use Transaction Safe Tables (TST). Advantages of Transaction-Safe Tables:
Safer. Even if MySQL crashes or you get hardware problems, you can get your data back, either by automatic recovery or from a backup + the transaction log.
You can combine many statements and accept these all in one go with the COMMIT command.
You can execute ROLLBACK to ignore your changes (if you are not running in auto-commit mode).
If an update fails, all your changes will be restored.
Concerning SQL Server
You should read "Transaction Behavior On Lost Connection" MSDN forum topic.
To understand better what lays behind MS SQL Server transactions, read a good article "Locks and Duration of Transactions in MS SQL Server"
Make sure you are not using any autocommit feature (I think that's enabled by default in some MySQL installations). If you do all your commits "manually", a broken connection will just result in you never committing the transaction and so it won't ever get written.
You cannot reconnect to rollback in most database systems.
We are using Livelink for our records management and if a user moves a folder with lost of sub folders it presents a lock on the database and slows the whole system down. Dispite sending many warnings out to users this is still happening. Is there any sort or monitoring tool that will give us a an early warning system as to when the locks occur?
If not what code would I use to run to show locks and to present with the username of who is causing the locks?
Thanks
I have no idea what Livelink is and I have no clue what documents, folders and movements you're talking about. That being said, since you mention locks and you tagged your question SQL Server: in a SQL Server system lock contention can be greatly reduced by deploying snapshot isolation models, see Using Snapshot Isolation. So simply enable read_committed snapshot and this will unblock any read performed under the default, read committed, isolation level:
ALTER DATABASE [dbname] SET READ_COMMITTED_SNAPSHOT ON;