On 06/25/14 11:52, Roman Simakov wrote: > 2014-06-25 11:24 GMT+04:00 Alex Peshkoff <peshk...@mail.ru>: >> A sample. >> Warehouse has a number of workplaces with computers for shipping goods. >> At some workplace in the beginning of a day were shipped some antennas, >> books and computers. I.e. we are at the top of the grid, cursor is >> opened but not fetched to the end. Next client wants some umbrellas and >> asks how much is present now. Grid is scrolled up to umbrellas - and >> please answer what quantity of them do we prefer to see - current or >> present at the beginning of a day? > present at the opening cursor. IMO it's bad style to open cursor. It > may keep open transaction (it's also not good but RO+RC possible) but > it should not keep open cursor. I do not understand why to open cursor > at all if you are not going to fetch right now.
Because cursor is big and you have 2G connection :) Getting serious - some APIs (like MS SQL one) really require to fetch all data before opening next cursor (i.e. not more than one cursor per server attachment). Our API makes it possible to have many opened cursor simultaneously, and this implies that one is not forced to fetch all data right after opening cursor. > Open, read correct result, close. Anyway, developers who want to build > such "strange" systems still can say to server to use > isc_tpb_insensitive_cursor. They need not do it before. And such applications may already exist. Certainly the sample I've provided is more than artificial. I just wanted to show that in theory such requirements is not something impossible. >>> It's enough for me to >>> make a conclusion to have new behavior as default. Some developers who >>> really understand that such situation cannot happen in his system can >>> EXPLICITLY specify TPB option isc_tpb_insensitive_cursor. I assume >>> current applications relies on logically correct result so backward >>> compatibility will not be broken. >>> >> They also rely on the fact that RO RC transaction does not prevent GC... >> And when one is using RC transaction he must be ready to get not >> consistent data in it. > IMO logical correctness is the first then GC. AFAIU we not prevent GC > in transaction. We prevent GC in requests. > > if one wants logical correctness he can always open snapshot transaction, fetch data from cursor (I remember you like to do it at once) and rollback transaction. ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
