<p>Developer looking for best method to identify a deadlock on a specific transaction inside a specific thread.  We are getting deadlock errors but these are very general in FB 2.0</p>

<p>Deadlocks happening and they are leading to breakdowns in the DB connection between client and the DB.  </p>

<ul>
<li>We send live ( once a second) data to the DB.  </li>
<li>We open a thread pool of around 30 threads and use them to ingest the data ( about 1-2 kB each second).  </li>
<li>Sometimes the DB can only take so much that we use the next thread in the pool to keep the stream current as possible.  </li>
</ul>

<p>On occasion this produces a deadlock in addition to reaching the max thread count and breaking the connection. </p>

<p>So we really need opinions on if this is the best method to ingest this amount of data every second.  We have up to 100 on these clients hitting the DB at the same time.<br>
Average transactions are about 1.5 to 1.8 million per day.</p>

I don't know of a specific way to identify the particular thread or statement. I've had to deal with FB deadlocks many times. You probably have two theads that are trying to update the same row in some table but they are doing it in separate transactions.
The best solution I've found is to design things so threads never have to update a row that any other thread might update. Sometimes that means having a thread that just exists to update a common table/row. The worker threads send a message to this thread. (The message could be done via another table.)
We run FB in many systems in the field that generate transactions (not millions per day) and we have found FB to be rock solid once we get the design correct.