Vlad F,

посередь минорных версий? Не, сейчас такое только у Интербэйза.

Vlad FЕсли ты про новую сборку
"новая сборка" - это 3.0.4, 3.0.5, 3.0.6...
4.0 - это не сборка, это версия.

Дегтярев Евгенийя правильно понимаю, что каждый процесс классика хранит это состояние и синхронизирует при изменениях?
хранит - да, но "синхронизирует" - нет. Нечего там синхронизировать. При snapshot читается TIP от OIT до Next, и дальше всё - транзакция сама никак TIP не меняет, никакая.
Еще раз - RC обращается к глобальному TIP, периодически, при проверке состояния транзакций у читаемых версий, на то она и read committed. Поэтому RC хранить у себя копию TIP незачем.
А Snapshot делает себе "личную копию TIP" именно для того, чтобы не видеть ничьих чужих изменений, и "перечитывать TIP" ей без надобности.
Так что, в общем, и у snapshot, да и у RC нет никакой "синхронизации TIP".
А глобальный TIP (в базе) меняется только когда какая-то транзакция завершилась.

кроме того, не "каждый процесс классика", а просто каждый коннект в любой архитектуре - CS, SC, SS. По потреблению памяти этот самый TIP влияет одинаково. Разница тут только в раздельном кэше БД у CS-SC и SS.

p.s. либо объясните, что имеете в виду под "синхронизацией". Лично я тут её не усматриваю.

Дегтярев ЕвгенийВлад выше сказал обратное.
ничего он обратного не сказал, см. его ответ ниже.

Я специально умолчал про кэш, потому что этот механизм несколько сбоку в отношении пресловутой мифической "синхронизации TIP". Достаточно понять, что я именно написал, и прочитать хоть чуть-чуть как транзакции меняют свое состояние, и как отслеживают состояния других транзакций, чтобы перестать говорить про "синхронизацию".
Может я нагнетаю, но мне кажется, что вы под синхронизацией представляете нечто другое, чем происходит на самом деле.

Дегтярев Евгенийможет быть миллион и чтобы это эффективно работало, надо чтобы эти данные были в памяти процесса.
за это отвечает КЭШ. Точно так же как и за синхронизацию изменений на страницах данных. Движок же в процессе работы транзакций и чтения версий ПРОВЕРЯЕТ состояния транзакций, либо из копии snapshot, либо из tip базы.

Дегтярев Евгенийя говорил про процессы
процессы дофига чего синхронизируют между собой через lock manager, например. Модификацию одной и той же страницы из разных транзакций, и т.д. Без "синхронизации" мульти-юзер доступ просто бы не работал.
Дегтярев Евгенийполучается при каждом комите надо TIP синхронизировать в 4к процессов.
вот не получается. При коммите движок записывает в TIP изменение состояния конкретной транзакции.
Если другим RC-транзакциям надо проверить версию этой транзакции, то они прочитают измененную страницу с этим куском с диска. Snapshot транзакции будут проверять состояния других транзакций только в локальной копии, никто никуда лазить не будет, и синхронизировать тоже.
авторно достаточно чтобы одна кривая апликуха, держащая OIT, поставила всю систему на колени.
извините, но это полная ерунда.
Во-первых, никакая аппликуха не держит OIT. OIT, в отличие от OAT, это давно завершившаяся роллбэком транзакция.
Во-вторых, чем она "поставит систему на колени"?

Если же тут перепутано, и имелось в виду OAT, так
- надо для читающих использовать read read committed. Тогда никаких длинных OAT не будет.
- не надо держать долго read write read committed в приложениях.
Собственно, опять же, "на колени" - это когда дофига версий и старая OAT. Нет версий - нет тормозов.

Vlad FЯ про новую сборку мусора.
сборка мусора - это сборка мусора. А просто сборка - это не сборка мусора. :-)

Дегтярев Евгений,

на всякий случай - мне к последнему ответу hvlad добавить нечего.

Vlad F,

я не словоблуд. Это проблема русского языка, что слово build - сборка и фраза "garbage collection" - сборка мусора -
начинаются в русском языке с одного и того же слова. Поэтому для меня "сборка" не является "сборкой мусора", даже при разнице в одно сообщение. К тому же, речь шла в том числе про новую фичу ФБ 4, которую тоже можно назвать "сборкой".
А насчет - "меня не спрашивали" - ну ок, не буду отвечать тогда.