On Thu, 29 Sep 2011 15:40:52 +0100, Scott Morgan <bl...@blueyonder.co.uk> wrote: > Think this might be related to > http://tracker.firebirdsql.org/browse/DNET-382 > > I've been hitting a deadlock between the GC and main threads. > > Examining it I've seen that the main thread calls FbTransaction.Rollback
> which, in sequence, locks: > 1. The transaction object itself > 2. database.SyncObject > 3. A GdsStatement object > > Whilst the GC thread is calling FbCommand.Dispose, which locks: > 1. The command object > 2. The same GdsStatement object as above > 3. database.SyncObject > > (call stacks at end of mail) > > Obviously there's a race condition here, between the statement and the > SyncObject. > > As a temporary fix I changed all locks to refer to the > database.SyncObject, which isn't pretty in terms of scaling, but does > remove the deadlock. > > A better solution might involve adding a transaction synch object, not > sure though, as I haven't really had the time to go through the code fully. The solution would at minimum require that FbCommand.Dispose sync in the exact same order as Rollback (so first database.syncObject, and then GdsStatement) (or that Rollback use the exact same order as in Dispose). Then it is impossible for deadlock to occur (assuming that the transaction isn't locked further on the Dispose method). Mark ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
