Nikolay Samofatov <nikolay.samofa...@red-soft.biz> писал(а) в своём письме Sat, 21 Jun 2014 01:52:46 +0400:
> Hello, All! > > We have encountered subtle errors and data corruptions when using > complex triggers/stored procedures > in READ COMMITTED transactions. > Most applied programmers don't think that while their SP/trigger is > executing the world is changing > underneath them. > So lost updates and inconsistent data changes are happening during > concurrent operation. > > To address this problem, in our engine builds we changed behavior of > READ COMMITTED + REC_VERSION > transactions to ensure cursor stability. > Each request is executed in its own snapshot, that is released when > execution of request ends. > We tried to be extra careful not to hurt performance while establishing > these snapshots. We do it > much more efficiently than done for isc_tpb_concurrency. > > This mimics Oracle's behavior in that regard but Oracle doesn't always > implement nesting correctly, > we do. > > I attach patch for this functionality to give you an idea of > implementation. It depends on a couple > other changes so it doesn't apply to FB2.5 cleanly. > > Any objections if I start porting this functionality to FB3? > A long-running transaction READ READ_COMMITED will not keep the garbage? Maybe we should introduce a new key TPB, if you want to maintain compatibility. Dimitry Sibiryakov no it's not. There was a patch to ignore the changes in the process of changing the cursor DML statement. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel