Зимата ни изненада

 Общи  Коментарите са изключени за Зимата ни изненада
Дек. 212009
 

Не става дума за общината или пътната агенция. А за нас, шофьорите.

В прословутия задръстен петък, когато цяла София орева света колко непочистени са улиците, аз пътувах малко под 2 часа до офиса. Честно казано, винаги при първия голям снеговалеж става екшън. Докато зацепи тромавата машина, отговорна за снегопочистването – и то вече наваляло. После за няколко часа все пак се справят и до края на деня основните улици са много добре почтистени. Както беше и тази година.

Не така стои въпросът със стотиците хиляди шофьори, които си мислят, че зимата може да се кара с летни гуми. Примерът е точно то петък. По малкото баирче от Малинов към Цариградско беше брутално задръстване, както на всяко друго място. Колите бяха в 2 колони и придвижването ставаше на етапи – тръгваш, пълзиш, спираш, чакаш и пак тръгваш. Ако можеш.

Точно пред мен имаше един червен Сеат, който след спирането не можа да потегли. Сега, вярно, пътят не беше изблизан до асфалт, ама няма как да разчиташ, че винаги ще е. Те за това има зимни и летни гуми. Та спира сеата по средата на баирчето, и като потегля колоната пред него, той започва да върти гуми. Напред не мръдва, ама яко се унесе на дясно към „другата“ лента (в която имаше автобус 76). Като видях какво става, пуснах едни аварийки и слязох да предложа да го бутна (няма как да върна назад – колоната не мърда назад).

Пича, обаче, съвсем рационално отказа моята помощ. Защото вече беше почти опрял в автобуса. Изчака дясната колона да мине достатъчно, че да се източи автобуса и при две свободни „ленти“ успя да потегли на зиг-заг. Качи баирчето с постоянно въртене на гуми и обиколки от едната лента в другата.

Аз, естествено, се притесних и за себе си. Все пак на гладък лед и зимните гуми не помагат. Пътят не изглеждаше точно като гладък лед, ама като гледах мъките на сеата… и нали съм спрял на същото място…

Да, ама не. Рендето си потегли съвсем безгрижно. Т.е. пътя не е бил съвсем на стъкло, просто заснежен. И се чудя с кой ли акъл е тръгнал тоя. И пак е късметлия, че закъса на горе. Защото ако гумите те предадат по надолнище, го отнасяш и ти, и невинните пред теб.

* * *

В събота улиците бяха перфектно почистени. Стигнах до работа за 35 минути. Както и днес. Но то нямаше и голямо движение. Явно тия с „цървулите“ бяха разбрали по трудния начин, че така няма да стане. Пак. Всяка година при първия сняг улиците се задръстват от тях. Хем то и през прозореца се вижда, че вече не е лято. Ама те да опитат…

* * *

Миналата зима. Имаше доста навалял сняг. Прецених, че ще видя зор да изляза от паркинга пред блока. Извадих от багажника една лопата, която си нося по цяла зима за такива случаи (да е жив и здрав Весо, че ми я подари) и си разринах. Като ме видя една съседка помоли да и дам лопатата, да си почисти и тя пред нейната кола. Аз съвсем кавалерски отидох лично да и разрина. Завързахме лаф и подхвърлих, че ако е с добри гуми няма да има проблем – стигне ли до пътя. Тя каза, че гумите и са много зле.

Зачудих се къде ли е тръгнала в тоя сняг, щом няма добри гуми. След като и разринах, на бегом се върнах до моята кола и се изнизах преди да е запушила пътя.

* * *

Срещу офиса има гумаджийница. Днес има голяма опашка, както беше и в петък и събота. Някои коли не могат да се качат на тротоара да си изчакат реда – то с галошите трудно става… Е сега ли е момента да си сменяш гумите? Сигурно още по-големи са опашките пред тенекеджийниците 🙁

 Posted by at 15:22
Дек. 212009
 

(към част 4)

С предишната част от поредицата показах един малко използван и доста мощен вариант за защита. В повечет случаи той е „прекалено“ ограничаващ (харесвам термина scalability inhibitor). Но може да се окаже полезен в случаи, когато едни данни се модифицират от токова много и различни места кода, че никой не ги знае всичките (спагети).

Обратно, когато се знае точно кои парчета от кода ще достъпват данните, се дефинират критични секции. За целта може да използва много интелигентно заключване с помощта на пакета dbms_lock. Този пакет предоставя възможност да се използват познатите ни вградени в Оracle механизми за заключване, за да управляваме достъпа до „наши“ си ресурси. Основно предимство пред hand-made заключваниците е, че механизма е доказан, тестван, железен и познат. За да може потребителя да използва този механизъм, трябва да има права за изпълнение на dbms_lock.

Ето малко примерен код:

create or replace procedure Process_New_Data is
  lck_handle number;
  lck_result binary_integer;
begin
  -- preventing multiple sessions run the same code
  DBMS_LOCK.ALLOCATE_UNIQUE(lockname => 'New_data_processing', lockhandle => lck_handle);
  lck_result := DBMS_LOCK.REQUEST(lockhandle => lck_handle, lockmode => dbms_lock.X_MODE, timeout => 0,
                                  release_on_commit => false);
  /* possible results:
    0 - Success; 1 - Timeout; 2 - Deadlock; 3 - Parameter error; 
    4 - Already own lock specified by id or lockhandle; 5 - Illegal lock handle
  */
  if lck_result != 0 then
    RAISE_APPLICATION_ERROR(-20115, 'Cannot allocate lock New_data_processing: ' || lck_result);
  end if;

  -- do wathever we want
  loop 
    insert . . .;
    delete . . .;
    commit; -- we can do many transactions, the lock is defined with release_on_commit => false
  end loop;
  update . . .;
  commit;

  -- release the lock
  lck_result := DBMS_LOCK.release(lockhandle => lck_handle);

EXCEPTION
  WHEN OTHERS THEN
    -- we should always release the lock!!!
    lck_result := DBMS_LOCK.release(lockhandle => lck_handle);
    -- do whatever error handling we need
    rollback;
    insert into Processing_log
      (time, module, action, error_msg, extra_data, status)
    values
      (sysdate, 'Process_New_Data', null,
       DBMS_UTILITY.FORMAT_ERROR_STACK() || chr(13) ||
       DBMS_UTILITY.FORMAT_ERROR_BACKTRACE(),
       null, 'Error');
    commit;
    raise;
end;

Основните моменти тук са:

– В началото си дефинираме „ресурс“, който ще заключваме, с помощта на DBMS_LOCK.ALLOCATE_UNIQUE

– После правим опит за заключване на този ресурс с DBMS_LOCK.REQUEST. Тук могат да се използват различни нива на закючване (Shared, Exclusive, SubShared, SubExclusive, Shared SubExclusive).
Може да изчакаме известно време (timeout) – това е много полезно, ако се очаква ресурса да бъде заключван за кратко, след което ние можем да успеем да го получим.
Има и още един много приятен параметър: release_on_commit. С него управляваме дали заключването да се освобождава автоматично при приключване на транзакцията (както правят всички нормални заключваници).
Една важна подробност е, че при неуспех процедурата не връща exception. За това трябва да се обработи резултата, който връща.

– След това може да се прави всичко според бизнес изискванията. Ако заключването е направено с release_on_commit => false, спокойно може да се реализира и код с много транзакции (като в част 1).

– На края ресурса се отключва с DBMS_LOCK.RELEASE. Тук отново при неуспех няма exception, а различен return value.

– Важно е да се подсигури „отключването“ на ресурса с exception handler. Ако по някаква причина не го направим и процедурата „гръмне“ по средата, той ще си остане заключен до края на сесията.

 Posted by at 13:27