Освобождение ресурса в finally

← →
Loginov Dmitry © (2008-05-08 13:36) [600]

> понимаешь, Дим, если бы все так было просто, что сводилось
> к освобождению лишь объектов... так ведь полным полно других
> ресурсов, требующих защитить и гарантированно освободить
> в конце работы...

Это все понятно.
Зато в файналли - одна строка и отсутсвие присваиваний NIL (это преимущества, которое я увидел в данном способе). Естественно, работает только для объектов.
Имхо, и такой подход имеет право на существования в определенных случая...

← →
Palladin © (2008-05-08 13:37) [601]

> Имхо, и такой подход имеет право на существования в определенных
> случая...

) все на свете имеет право на существование... вот только на долго ли...

← →
ANB (2008-05-08 13:38) [602]

> Единственно - в файналли строка одна.

> хреновое решение :) кто поинтеры в List1, List2 и List3
> освобождать будет?

Мона занаследовать TList и в его деструкторе зачищать объекты в поинтерах.

Тока

> так ведь полным полно других ресурсов

рубит всю эту идею на корню.

> Palladin © (08.05.08 13:16) [598]

Так придумал, как решить задачку, пользуясь только SQL-92 ?
ИМХО - программер, начав использовать Т-скл - прав.
И к этому приходят все, кто пытался делать универсальные приложения под все СУБД.
Ты даже базу так просто один к одному с сервера на сервер не перетащишь, т.к. не все типы данных совпадают.

← →
Palladin © (2008-05-08 13:39) [603]

> Так придумал, как решить задачку, пользуясь только SQL-92
> ?
> ИМХО - программер, начав использовать Т-скл - прав.
> И к этому приходят все, кто пытался делать универсальные
> приложения под все СУБД.
> Ты даже базу так просто один к одному с сервера на сервер
> не перетащишь, т.к. не все типы данных совпадают.

слухай, ну я ж сказал, моня я потом отвечу... после праздников... я не тяну время, мне просто сейчас думать лень...

← →
Игорь Шевченко © (2008-05-08 13:48) [604]

ANB (08.05.08 13:12) [595]

> Эт чего такое ?

Это Fine-grained access

> Знаю, что у оракла мона настроить хитро права на чтение
> таблиц. Но фактически это работает как обычная вьюха.
> Следовательно, может невовремя вызвать жуткие тормоза.

Я тебе открою страшный секрет (только не выдавай меня) - вьюхи в оракл тормозов не вызывают. Неоткуда им там взяться, тормозам при вьюхах.

> Комплексное тестирование - вообще редкость.
> А качественное комплексное тестирование - эт ваще что то
> на грани фантастики.

Это сугубо ваши личные проблемы и распространять последствия вашего бардака на парадигмы разработки - дурной признак.

← →
Игорь Шевченко © (2008-05-08 13:49) [605]

> Очевидное решение, позволяющая с помощью одного try..finally
> защитить сразу множество ресурсов:

Разыщи портрет Оккама и повесь перед монитором, дабы он напоминал тебе - не плоди сущностей сверх необходимости.

← →
ANB (2008-05-08 16:48) [606]

> Это Fine-grained access

А. Тогда про это я читал. Знающие люди сказали, что оно того не стоит и практически никто этим не пользуется.

> Я тебе открою страшный секрет (только не выдавай меня) -
> вьюхи в оракл тормозов не вызывают. Неоткуда им там взяться,
> тормозам при вьюхах.

Ну надо же. И чего я дурак мучился, разбирал вьюхи на таблицы и обращался к ним напрямую, чтобы ускорить запрос с 2-х часов до 2-х секунд ?
Открою по секрету - тормозят даже вьюхи словаря, особенно в связках.

← →
ANB (2008-05-08 16:51) [607]

> Это сугубо ваши личные проблемы и распространять последствия
> вашего бардака на парадигмы разработки - дурной признак.
>

Дык он почти везде такой бардак. Чтобы провести комплекс нашей АБС, нужно около 6 человекомесяцев.

А если при этом тестер будет наступать на ошибки из-за опечаток программиста, то еще дольше.

← →
MsGuns © (2008-05-09 03:37) [608]

>ANB (08.05.08 16:51) [607]
>Дык он почти везде такой бардак. Чтобы провести комплекс нашей АБС, нужно около 6 человекомесяцев

Это таки да. Как и то, что для того, чтобы вкрутить лампочку надо 9 милиционеров.

← →
ANB (2008-05-12 09:54) [609]

> чтобы вкрутить лампочку надо 9 милиционеров.

И чтобы заменить 9 милиционеров на одного электрика лучше (но не обязательно :) ) писать так, чтобы ошибок было меньше. И если среда умеет ловить ошибки хотя бы синтаксические и грамматические, то хорошо этим пользоваться. Все равно еще логические ошибки отслеживать.

← →
Arinyshka (2008-05-12 12:46) [610]

Я горжусь собой... подбросить тему для такой дискуссии... :)

← →
Anatoly Podgoretsky © (2008-05-12 13:04) [611]

> Arinyshka (12.05.2008 12:46:10) [610]

Дурное дело не хитрое.

← →
Игорь Шевченко © (2008-05-12 13:10) [612]

ANB (08.05.08 16:48) [606]

> А. Тогда про это я читал. Знающие люди сказали, что оно
> того не стоит и практически никто этим не пользуется.

"Не верь, хозяин, этому констанинопольскому ходже" (с) Габровские уловки.

Ты лучше Кайта почитай, он с картинками рассказывает, как этим пользоваться, во втором томе.

> Ну надо же. И чего я дурак мучился, разбирал вьюхи на таблицы
> и обращался к ним напрямую, чтобы ускорить запрос с 2-х
> часов до 2-х секунд ?

Вот странно. Количество таблиц не изменилось, количество связок между ними тоже, а скорость взяла и в 3600 раз увеличилась.
Станиславский тут же вспоминается.

А что тебе трассировка события 10053 рассказала ? :)

← →
ANB (2008-05-12 14:36) [613]

> Ты лучше Кайта почитай, он с картинками рассказывает, как
> этим пользоваться, во втором томе.

Я читал оригинальную доку от оракл.
И даже попробовал. Геморр еще тот. А толку - та практически таже вьюха.

> Вот странно. Количество таблиц не изменилось, количество
> связок между ними тоже, а скорость взяла и в 3600 раз увеличилась.
>
> Станиславский тут же вспоминается.

Были выброшены лишние таблицы. Именно за счет отказа от вьюх.
И за счет этого резко возрасла скорость.
Попробуй аккуратно развернуть внешние ключи таблицы (сгенерить DDL). А потом попробуй сделать это для всех таблиц в схеме.

← →
Игорь Шевченко © (2008-05-12 14:50) [614]

ANB (12.05.08 14:36) [613]

> Были выброшены лишние таблицы. Именно за счет отказа от
> вьюх.
> И за счет этого резко возрасла скорость.

То есть, ты сначала создаешь себе трудности, а потом их мужественно преодолеваешь ?
Бывает.

Я-то имел в виду несколько иное, когда view не содержит внутри дополнительных соединений, тогда она тормозов ну никак не создает.

← →
Palladin © (2008-05-12 15:14) [615]

> ANB

> В одном месте ? Минимум 2 : скрипт для модификации базы
> и поправить ваши скл скрипты для "сериализации".
> Плюс все скрипты отчетов, где используется это поле. Плюс
> связка "имя поля таблицы" - "имя поля в классе - обертке".
>
>
> А если поле добавилось ? У вас клиент тонкий и всю инфу
> о полях и формах ввода тянет с аппсервера ?

И что? Причем тут собственно многозвенность? Клиент да, тонкий, он тянет только информацию о том как ему построить форму параметров отчета. Буквально 100, 200 строчек

> В оракле это делается совсем по другому. Так же как в ФБ/ИБ.
>
> И трехслойка тут все переделать никак не поможет.

опа... а кто-то тут не собирался до синтаксиса докапываться... интересный ход событий...

> Надеюсь, не на каждую сущность отдельное приложение ?
>
> А сколько всего таблиц нарисовать успели ?

причем тут таблицы? сущность, в рамках архитектуры, это более сложное понятие чем ты думаешь...

> Это для всех отчетов или для каждого ?

для каждого

> Ты успел поработать в банке ? Обалдеть.

я не работал в банке, я работаю на банк, конкретный, пишу для них софт и тесно общаюсь с ихними спецами...

> А теперь напиши тоже самое с использованием SQL-92.
> Можно без оболочки с паскалем - чисто SQL. И мона с ошибками. Главное - принцип.
> Так придумал, как решить задачку, пользуясь только SQL-92
> ?

хем... а собственно зачем? на кой мне это надо если это решается PS?

При работе через SQL-92 идет Connection.BeginTrans/Commit на каждый вызов... про это я уже писал...

> ИМХО - программер, начав использовать Т-скл - прав.
> И к этому приходят все, кто пытался делать универсальные
> приложения под все СУБД.
> Ты даже базу так просто один к одному с сервера на сервер
> не перетащишь, т.к. не все типы данных совпадают.

ну молодец значит, выпишем ему премию...

а вот теперь скажи, о ярый решатель всего с использованием оракла, при чем здесь многозвенка?

единственное слабое место, это да, ситуевина с мастер-детаил в транзакции... в прочем, это так, нюанс...

← →
Palladin © (2008-05-12 15:17) [616]

конкретно,

1. мне не совсем понятна связь между объемом БД и многозвенностью
2. мне не совсем понятна связь между меняющейся структурой каких либо таблиц и SQL/PS скриптов для обработки данных, многозвенность то тут причем... двузвенное приложение подобными проблемами не обладает?

← →
Palladin © (2008-05-12 15:30) [617]

у меня, в ходе дискуссии, родилось ощущение, что ты однажды нагородил себе тех проблем, которыми пытаешься меня озадачить, а теперь просто продвигаешь свое суперское их решение на основе оракла... (костыли в виде DCOM и пр)... бо все остальное - есть лжерешения от лукавого... а как их решить на основе многозвенки ты даже и задумываться не хочешь, такая же ситуевина у тебя и с ООП, ты даже не хочешь задумыватся, что задачи решенные тобою функционально, решаются совсем в другом ракурсе видения проблеммы и это решение может обладает своим, уникальным, преимуществом...

← →
ANB (2008-05-12 16:30) [618]

> Я-то имел в виду несколько иное, когда view не содержит
> внутри дополнительных соединений, тогда она тормозов ну
> никак не создает.

А как тогда права проверять ?

← →
ANB (2008-05-12 16:46) [619]

>
> опа... а кто-то тут не собирался до синтаксиса докапываться.
> .. интересный ход событий...

А я до него и не докапывался.
Я хотел доказать тебе, что на SQL-92 написать нормально НЕВОЗМОЖНО.
Самая простая проблема - получить ID только что сгенеренной записи ставит тебя в тупик.
Она легко решается использованием особенностей диалекта конкретной СУБД.

> на кой мне это надо если это решается PS?

Судя по приведенному коду, это таки решается через Т-СКЛ. Или раз пишешь не ты - то значит нет проблем ? Надо и коллегах думать.

> многозвенность то тут причем... двузвенное приложение подобными
> проблемами не обладает?

А аппсервер тебе эти проблемы решил ?

Вот скажи, какие проблемы ты конкретно решил, написав толстый аппсервер с засунутой внутрь бизнес-логикой ? И какие - применив обертку ООП над реляционной моделью (пользуясь при этом реляционной СУБД) ?

> мне не совсем понятна связь между объемом БД и многозвенностью

С многозвенностью - никак не связана. Тормоза вызовет именно обертка ООП.

> Клиент да, тонкий, он тянет только информацию о том как
> ему построить форму параметров отчета.

А формы для ввода данных он тоже сам рисует ? На основе присланных аппсервером метаданных ?

Если так, то приложение почти идеально. Универсального клиента много кто пытался писать. Но все время в процессе сопровождения начинают вылезать сложные формы, которые так просто метаданными не опишешь.
Приходится прикручивать редактор форм. Ну и начинается изобретение собственной IDE. Довольно спорный путь (хотя я и не против него).

Фактически осталось 2 слоя, которые надо править.

Вот только в таком случае можно оставить ОДНО место, пойдя чуток дальше и перенеся бизнес-логику на сервер СУБД.
И работать будет быстрее. И писать проще.

> (костыли в виде DCOM и пр)

А зачем ораклу эти костыли ?

← →
Игорь Шевченко © (2008-05-12 16:52) [620]

ANB (12.05.08 16:30) [618]

> А как тогда права проверять ?

Права надо не проверять, а раздавать. После раздачи их проверяет сервер. Грубо говоря - если тебе дали доступ к объекту, ты можешь выполнять некие операции с ним. Если нужна настройка прав на уровне строк, то добро пожаловать в FGA.

В противном случае ты сам занимаешься разработкой имитации FGA на PL/SQL, в то время как он написан на С и выполняется слегка быстрее...

← →
ANB (2008-05-12 17:08) [621]

> > Надеюсь, не на каждую сущность отдельное приложение ?
> >
> > А сколько всего таблиц нарисовать успели ?
>
> причем тут таблицы? сущность, в рамках архитектуры, это
> более сложное понятие чем ты думаешь...

Я спрашивал про количество таблиц, а не сущностей.

← →
ANB (2008-05-12 17:09) [622]

> Если нужна настройка прав на уровне строк, то добро пожаловать
> в FGA.

И чем он ФГА будет отличаться по результата от вьюхи с заджойненной таблицей прав ?

← →
Игорь Шевченко © (2008-05-12 17:15) [623]

ANB (12.05.08 17:09) [622]

Ну зачем я тебе буду Кайта пересказывать, его же можно прочитать, том 2, глава 21, "Тщательный контроль доступа".

← →
Palladin © (2008-05-12 17:44) [624]

> ANB

извини, но ты опять понес какую то пургу...

> А я до него и не докапывался.
> Я хотел доказать тебе, что на SQL-92 написать нормально
> НЕВОЗМОЖНО.
> Самая простая проблема - получить ID только что сгенеренной
> записи ставит тебя в тупик.
> Она легко решается использованием особенностей диалекта
> конкретной СУБД.

ну хорошо, пусть невозможно, пусть решается на уровене PS, что дальше? пусть придется поменять PS на аппсервере при уходе от t-sql

ладно, хорошо, истинной, идеальной независимости от БД не получается, так же как и в двузвенке...

> Вот скажи, какие проблемы ты конкретно решил, написав толстый
> аппсервер с засунутой внутрь бизнес-логикой ? И какие -
> применив обертку ООП над реляционной моделью (пользуясь
> при этом реляционной СУБД) ?

да как бы давно уже сказал... читать нужно внимательней... или ты не читал и мне тебе указать конкретные номера постов?

>С многозвенностью - никак не связана. Тормоза вызовет именно обертка ООП.

конкретней, пожалуйста. в чем они будут заключатся?

> А формы для ввода данных он тоже сам рисует ? На основе
> присланных аппсервером метаданных ?

да

> Ну и начинается изобретение собственной IDE.

а представь себе, да, она, иснтументалка низкого уровня, для разработчиков более высокого уровня и предназначена, мне уже все уши прожжужали этим: "человек, делающий отчеты, не должен знать о GetMem/FreeMem", а я куда денусь, партия сказала - значит надо

> Вот только в таком случае можно оставить ОДНО место, пойдя
> чуток дальше и перенеся бизнес-логику на сервер СУБД.
> И работать будет быстрее. И писать проще.

я этого никогда не сделаю, и не собираюсь, бизнес логика на аппсервере куда более абстрактна от ее же реализации на конкретной СУБД...

> А зачем ораклу эти костыли ?

ужо забыл про своё [506]?

← →
ANB (2008-05-12 18:06) [625]

> Ну дык у нас всегда так. Один проект, писавшийся 6 лет таким
> макаром практически завалили. Другой (ну там хоть понятно
> - мс скл), колбасит. До 15 патчей в неделю было 3 года назад.
> И проекту тогда было лет 7 как уже, из них 3 уже шли во
> всю боевые внедрения.
> Я даже могу понять, когда аппсервер крутится для сложных
> вычислений там или еще для чего то подобного.
> Я вот лепил микро - дком сервер. Но мне надо было :
> 1. Сделать эмулятор смарткарт отдельным приложением (чтобы
> руками мона было кнопки нажимать)
> 2. Прикрутить этот эмулятор к системе тестирования, чтобы
> в автомате кнопки нажимать в тестируемом приложении и при
> этом подсовывать ему разные карточки.
> И то я дком выбрал из-за самой простой реализации интерфейса
> между приложениями. Если б не торопился - может и чего другого
> придумал бы.
>
> А вот зачем самим писать слой между БД и клиентом - непонятно.
>

Где здесь DCOM - костыль к ораклу ?

← →
ANB (2008-05-12 18:13) [626]

> Palladin © (12.05.08 17:44) [624]

Изобретение второй 1С.
Так ее бы сразу и поставил. Тем более 8-ка - уже любимая тобой трехслойка.
Будет такая же тормозная.

> конкретней, пожалуйста. в чем они будут заключатся?

Лишние телодвижения, приводящие к тормозам на массовых операциях.

> я этого никогда не сделаю, и не собираюсь, бизнес логика
> на аппсервере куда более абстрактна от ее же реализации
> на конкретной СУБД...

Чем абстрактнее, тем тормознее. Тем более ты так и не избавился от зависимости от конкретной СУБД. Все равно все под МС СКЛ заточено.

Давай рассмотрим конкретную задачу : нужно изменить статус у около 100 000 документов по некоему фильтру (пусть будет по дате). Причем все в одной транзакции.

На оракле (и на мс скл) я все это решаю одним оператором. А так как это один оператор, то даже с транзакциями не надо заморачиваться - он либо выполниться, либо нет.

А как это сделаешь ты (включая неявное выполнение PS скриптов) ?

← →
ANB (2008-05-12 18:16) [627]

> В противном случае ты сам занимаешься разработкой имитации
> FGA на PL/SQL, в то время как он написан на С и выполняется
> слегка быстрее...

Послезавтра приду на работу и не поленюсь протестить.
Но что то мне говорит, что хранимка отработает быстрее.

← →
Игорь Шевченко © (2008-05-12 20:21) [628]

ANB (12.05.08 18:13) [626]

> Тем более ты так и не избавился от зависимости от конкретной
> СУБД

Я конечно сильно извиняюсь, что не по теме, но мысли об избавлении от зависимости от конкретной СУБД нужно гнать из головы, не дожидаясь, пока они там возникнут.

>ANB (12.05.08 16:46) [619]
>Я хотел доказать тебе, что на SQL-92 написать нормально НЕВОЗМОЖНО.

Плохому танцору ?

>Самая простая проблема - получить ID только что сгенеренной записи ставит тебя в тупик.

Где это, что-то не припоминаю

>Она легко решается использованием особенностей диалекта конкретной СУБД.

Зачем использовать диалекты там, где можно общаться на обычном языке ?

>Вот скажи, какие проблемы ты конкретно решил, написав толстый аппсервер с засунутой внутрь бизнес-логикой ?

Очень странные у тебя представления об "аппсерверах"

← →
ANB (2008-05-14 09:51) [630]

> Я конечно сильно извиняюсь, что не по теме, но мысли об
> избавлении от зависимости от конкретной СУБД нужно гнать
> из головы, не дожидаясь, пока они там возникнут.

А у меня они и не возникают. Посмотри описание проекта палладина, где как одно из достоинств применения трехслойки он заявляет о независимости от типа СУБД.

> >Самая простая проблема - получить ID только что сгенеренной
> записи ставит тебя в тупик.
>
> Где это, что-то не припоминаю

Узнать искусственный первичный ключ записи при вставке для того, чтобы использовать его во вставке дочерних записей.

> Очень странные у тебя представления об "аппсерверах"

Ну дык палладин написал аппсервер с бизнес-логикой внутри и оберткой в виде классов над сущностями БД.

> Узнать искусственный первичный ключ записи при вставке для
> того, чтобы использовать его во вставке дочерних записей

Э...а нафига ? Я до сих пор считал, что сущность как бы передается единым целым со всем ейными потрохами...

← →
ANB (2008-05-14 11:33) [632]

> Я до сих пор считал, что сущность как бы передается единым
> целым со всем ейными потрохами...

Куда передается ?

> ANB

если ты задался вопросом, как же я получаю значение счетчика в рамках SQL-92, то расскажу тебе страшную тайну, PK поле в бд - не счетчик...

← →
ANB (2008-05-14 12:01) [634]

> PK поле в бд - не счетчик...

Гуид что ли ?

и не гуид, обыкновенный int, без свойств identity/autoincrement, он не СУБД генерируется...

ANB (14.05.08 11:33) [632]

> Куда передается ?

Промеж клиентом и сервером, скорее всего.

>ANB (14.05.08 09:51) [630]
> >Самая простая проблема - получить ID только что сгенеренной
>> записи ставит тебя в тупик.
>> Где это, что-то не припоминаю

>Узнать искусственный первичный ключ записи при вставке для того, чтобы использовать его во вставке дочерних записей.

Я не припоминаю, где эта "проблема" ставила его "в тупик"

← →
ANB (2008-05-14 13:13) [638]

> Промеж клиентом и сервером, скорее всего.

каким сервером ? СУБД или приложений.

> Я не припоминаю, где эта "проблема" ставила его "в тупик"

А ответа так и не было. А тот, что был - был с использованием T-SQL.
А сейчас выясняется, что все ключи генерятся на аппсервере.

> ANB (14.05.08 13:13) [638]

обождите, ты мне задачу давал с чем? именно в этом был подвох то, в PK поле обладающим св-вом identity/autoincrement, а иначе задача твоя изюминкой никакой не обладает и никаких нюансов нет...

ты дал условия, я к этим условиям приспособил PS... эти нюансы в структуре БД, в принципе допустимы, в контексте аппсервера, но не рекомендуемы...

← →
ANB (2008-05-14 13:33) [640]

> обождите, ты мне задачу давал с чем? именно в этом был подвох
> то, в PK поле обладающим св-вом identity/autoincrement,
> а иначе задача твоя изюминкой никакой не обладает и никаких
> нюансов нет...
>
> ты дал условия, я к этим условиям приспособил PS... эти
> нюансы в структуре БД, в принципе допустимы, в контексте
> аппсервера, но не рекомендуемы...

Я просил изобразить, как в контексте твоего приложения, ты получаешь ID записи после/перед вставкой, чтобы потом использовать его дальше (например, для вставки дочерней записи).
В случае использования автоинкремента эта задача с использованием только SQL-92 не решается. Во всяком случае, корректно.
Однако, выясняется, что генерацией ключей занимается не СУБД, а аппсервер.
Гы. Ну, когда я писал на клиппере, у меня тоже ИД генерились на клиенте, но там просто не было другого способа.
А вот зачем использовать костыли при наличии нормальных серверов с генераторами ?

Освобождение ресурса в finally Найти похожие ветки