| 
		
			| Читающая транзакция FDTransaction  [сообщение #3725] | Wed, 15 November 2023 00:11  |  
			| 
				
				
					|  sashaua01 Сообщений: 26
 Зарегистрирован: July 2022
 | Junior Member |  |  |  
	| Добрый день подскажите пожалуйста, прочитал на просторах интернета. На старте апки создают и стартуют общую для всех читающую транзакцию с параметрами
 
 и такую транзакцию используют для чтения данних с базы (показ данных в гриде и т.п.)
Result.Options.Isolation:=xiReadCommitted;
Result.Options.ReadOnly:=True;
Result.Options.Params.Add('read read_commited rec_version');
Цитата:
 Транзакция с такими параметрами в Firebird может быть открытой сколь угодно долгое время (дни, недели, месяцы), без блокирования других транзакций или влияния на накопление мусора в базе данных завершают и уничтожают при закрытии апки. Насколько такой подход имеет право на жизнь? Создавать такую транзакцию в сингелтоне и когда надо использовать ее.
 |  
	|  |  | 
	|  | 
	|  | 
	|  | 
	|  | 
	| 
		
			| Re: Читающая транзакция FDTransaction  [сообщение #3766 является ответом на сообщение #3731] | Mon, 20 November 2023 14:26   |  
			| 
				
				
					|  shalamyansky Сообщений: 150
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| МП писал(а) Wed, 15 November 2023 16:48 Так read_commited транзакция всегда вернет актуальные данные, нет разве? Актуальные вернуть проще, что подтверждено, то и актуально. Это же не snapshot, чтобы заморачиваться реперными точками и т.п.тогда когда тебе нужны АКТУАЛЬНЫЕ данные вместо "протухших".
 
 
 ИМХО разница лишь в том, что делать старт/стор - хорошая привычка брать ресурс ровно настолько, сколько он нужен, и отпускать после. А не хватать и класть в долгий ящик "на всякий случай". Но если накладные расходы на старт/стор сравнимы уже с основными расходами, то можно, конечно, задуматься и о второй стратегии. Измерять надо.
 |  
	|  |  | 
	|  | 
	|  | 
	|  | 
	|  | 
	|  | 
	| 
		
			| Re: Читающая транзакция FDTransaction  [сообщение #3782 является ответом на сообщение #3778] | Mon, 20 November 2023 20:29   |  
			| 
				
				
					|  shalamyansky Сообщений: 150
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| МП писал(а) Mon, 20 November 2023 18:07  Хорошо, давайте рассмотрим. С Вашего позволения я буду рассматривать, а Вы рассказывать.для этого нужно просто рассмотреть вопрос ЗАЧЕМ ввели режим READ CONSISTENCY.
 
 
 Но перед этим на всякий случай давайте проверим тезис, а то есть подозрение, что рассуждения в сторону ушли. Мое утверждение состоит в том, что
 
 транзакция read_only read_commited (+-read_consistency) всегда читает актуальные данные, безотносительно момента её старта. Под актуальными данными подразумеваем последние в принципе доступные (подтвержденные) на момент запроса.
 
 Если Вы согласны с этим, то предмета спора нет, и я с большим интересом (никакой иронии) почитаю о причинах введения read_consistency. Если не согласны, то прошу объяснений.
 |  
	|  |  | 
	|  | 
	|  | 
	|  | 
	|  | 
	| 
		
			| Re: Читающая транзакция FDTransaction  [сообщение #3825 является ответом на сообщение #3795] | Wed, 22 November 2023 15:29  |  
			| 
				
				
					|  SD Сообщений: 452
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| МП писал(а) Tue, 21 November 2023 11:11 Именно поэтому read committed даже с read consistency для отчётов бесполезен. Если только не идти по ораклятому пути и не впихивать всю-всю выборку в один-единственный мегазапрос для которого эта consistency таки сработает.при построении отчётов в больших системах (по типу OLAP) каждый запрос может выполняться до десятков минут. и запросов таких в одном отчёте обычно N-е множество.
 
 |  
	|  |  |