Re: Error handling in Serviced Components

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Florin Lazar [MSFT] (florinlazar_at_online.microsoft.com)
Date: 05/31/04


Date: Sun, 30 May 2004 18:29:27 -0700

Hi Arpan,

It looks like your database is aborting the transaction when it detects the
deadlock. Setting DisableCommit will not help. You need to bubble up the
error outside the layer that started the transaction. You can't do any
database work as part of this doomed transaction.

Regards,

-- 
Florin Lazar - Microsoft - [ http://blogs.msdn.com/florinlazar ]
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Arpan Patel via .NET 247" <anonymous@dotnet247.com> wrote in message
news:OpcxQdROEHA.308@TK2MSFTNGP11.phx.gbl...
Hi all,
I am having a problem figuring out error handling with my serviced
component.  I am reading data from the database and I get deadlock errors.
To solve deadlock, i catch that error and resubmit it and i get following
error:  "Distributed transaction completed. Either enlist this session in a
new transaction or the NULL transaction."  Any idea what i can do here?  it
seems like that the transaction is setting to complete.  I have added code
to disable setcomplete but it still doesnt work.  Here is the psuedo code
for what i am doing:
private sub GetData(...)
Try
  GetDatafromDb()
Catch ex
  if error = deadlock then
ContextUtil.DisableCommit()
 GetData (resubmit)
else
   throw ex
End If
End Try
End sub
Please let me know what I am doing wrong.  Thank you.
--------------------------------
From: Arpan Patel
-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)
<Id>DWXCSg+RWEyWOU0Cpd/rpg==</Id>


Relevant Pages

  • Re: Theoretical Basis for SELECT FOR UPDATE
    ... >> neglected to eliminate non-serializable transaction histories. ... >> The way to avoid the deadlock is naturally to eliminate ... database one works with has to offer. ...
    (comp.databases.theory)
  • Re: concurrent transactions
    ... The deadlock is normal with any isolation level (it was my mistake in the ... Because that you need a locking hint when executing the select: ... You execute this with RC isolation level and will be fine. ... So I don't need a serializable transaction? ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: deadlocks between single update statements ?
    ... I guess one could think of the serializable transaction isolation ... session 2 gets row B ... session 1 detects deadlock and rolls back select statement. ... pretty widespread changes in the code base. ...
    (comp.databases.oracle.server)
  • RE: Deadlock Victum Error Message
    ... commit transaction ... both threads are accessing same resources but in ... After the deadlock is identified, ...
    (microsoft.public.sqlserver.programming)
  • RE: Deadlock Victum Error Message
    ... commit transaction ... both threads are accessing same resources but in ... After the deadlock is identified, ...
    (microsoft.public.vb.database)