At 10:15 PM 17/11/2008, you wrote: ...the developer told me that in Interbase and Firebird >writers don't lock readers. He said that I should add tpb_rec_version to my >transaction parameters block. Or ask driver's author to do so. This is to >avoid IBReplicator blocking my whole .NET app up for all other users when >replication is running. > >I did a google on 'tpb_rec_version' but am getting absolutely nowhere with >that. The previous thread seemed to be suggesting that the writer was >blocking the reader. but now i am confused after the latest reply. > >i am really just looking for a way for my users to be not frozen out whilst >IBReplicator is running. I am wondering id this tpb_rec_version is a >possible solution for the .NET driver. frankly I am a bit out of my depth >here so any expert opinion would be helpful. thanks.
The parameters isc_tpb_rec_version and isc_tpb_no_rec_version are the two possible values of a parameter that applies *only* to read committed transactions. For some strange reason, isc_tpb_no_rec_version is the default in a lot of drivers. The combination of isc_tpb_no_rec_version with read committed isolation and WAIT lock resolution in read/write mode is the *only* set of conditions where pending inserts to a table will block readers. isc_tpb_no_rec_version stipulates that your users' transactions must either WAIT until the pending writes are committed (WAIT resolution) or except immediately (NO WAIT resolution). So - if your users are working with big sets in read-write transactions with these attributes, life stops for everyone. With isc_tpb_rec_version, the latest committed version is considered the latest version, even if there are newer versions pending. In read committed read/write you still should take care with WAIT resolution, even without that mega-transaction from replication in the background. A lot of developers think read committed and WAIT are the "right" isolation for everything, too often, regrettably, because they don't want to have to handle exceptions or go into retry loops. This belief works against the very essence of smooth concurrency and pace in a multi-user, multi-functional environment. Use isc_tpb_no_rec_version and WAIT in conditions where a finite number of things are getting used up rapidly and randomly and there must be strict serialisation: issuing flight tickets, fast-turnover of allocations from warehouse systems that are shared by multiple branches, consumption and/or collection of cash, consumption and refreshment of supplies in the food trade. For these, don't run out massive sets to readers in read/write transactions. Have them find what they want from select lists in read-only read committed transactions; target one selected record for a write and commit or bounce the change immediately. WAIT means "wait and see", not "wait until Doomsday" nor even "wait until after lunch". And if the "see" part nearly always results in a bounce, anyway, then WAIT isn't right for your conditions at all. In most organisations, most operations are performed as a *result* of the furious activity in the warehouse, ticket office, point-of-sale, etc. Accounts payable, accounts receivable, supply ordering, payroll, sports results, etc., all happen routinely, with no fast-moving targets. Don't use read committed at all for these jobs. Under these conditions, use concurrency isolation. Conflicts are less likely, so the question WAIT/NO WAIT assumes less importance for data consistency and becomes a question more closely related to house rules and workflow organisation. If you are running reports, run them always in concurrency isolation, picking up the report date and time at the *beginning* of the transaction and storing it in a variable for referring to for time-based calculations. Read committed is too "dirty" to make reports reliable, as it allows database state to change between the start and finish of the report's transaction. (Reports run in read committed isolation should fail software and security audits.) Helen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Firebird-net-provider mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
