interconnecting asp and asp.net sessions

Recently I came across an interesting situation, I needed to synchronize asp and asp.net sessions(our application is a combination of old asp and new asp.net code).

The asp.net session timeout can be configured in web.config file, and after the specified timeout period elapses, session is being terminated - asp.net session not asp. In order to access the asp session variables, when asp.net session is terminated - I crafted web request that was sent to special asp file. In this file script cleans up session variables and the whole asp app thinks that its session is terminated.

The trick here was that all the cookies, that were created in the session, had to be present in the http request header. Asp page discovers its state using these cookies.

P.S. in the asp script to which the request will be sent it is necessary to compare the host that issued the request and local address - they must be the same. If not performing this check, this will leave security breach in the web app

Пошук витоків пам"яті у веб-програмах

Досить недавно проводили пошук витоків пам"яті ( memory leaks ) у нашій веб-програмі. Проблема була описана досить туманно: казали, що сервер використав багато пам"яті, при цьому не згадували, ні, що за програма була такої ненажерливою, ні умов при яких таке відбувалося. Сказали тільки, що після 3-ьох днів роботи програми, сервер потрібно було перезавантажувати.

Це була передісторія. Тепер розкажу, як це все тестувалося... Є така прорама, як Microsoft Application Test Center, вона дозволяє проводити стрес тести для веб-програм. Принцип дії дуже простий - програміст створює проект, потім записує всі свої дії у броузері. Далі генерується код на VB, що відповідає діям користувача. Ось і все - тест готовий, можна починати тестування.

Так як наша програма була спочатку написана індусами, тому перш за все ми подивилися на код. Якість останнього залишала бажати кращого: код досить путаний, до того багато місць у яких пам"ять може "тікти". Наприклад на сервері створюється об"єкт ADODB.Connection, котрий потім не знищується. Таких місць у коді було досить багато. Іншим інструментом, яким ми користувалися був AdoMonitor 1.0 ( http://www.troxo.com/products/adomonitor/ ) - дозволяє трасувати все, що відбувається з ADO.

Цікавий факт, якщо залишити asp код таким, яким він був, тобто з витоками пам"яті,то - після 4-ох хвилин роботи веб-сервер "підвисав" і починав працювати тільки після того, як його перевантажать. Інший цікавий факт, був пов"язаний з ADO, виходить, що на стабільність нижче наведений код ніяк не впливає, так само, як і на витоки пам"яті:

Set cn = server.CreateObject("ADODB.Connection")
cn.ConnectionString = someConnectionString
cn.Open
'cn.Close можна навіть не викликати, об"єкт буде знищено все одно, а з"єднання 'повернеться у пул
cn = Nothing