Попередньо відкомпільовані (підготовлені) запити

Іноді виникає необхідність виконання схожих SQL запитів декілька раз підряд. В цьому випадку використання попередньо відкомпільованих запитів виявляється більш ефективним, ніж виконання одного і того самого запиту декілька раз. Попередньо відкомпільовані запити подібні до деяких шаблонів, в які необхідно будувати дані та надіслати ці дані до СУБД. Параметризований шаблон запиту надсилається до СУБД на компіляцію. Після етапу компіляції, він зберігається в кеші СУБД і для його виконання клієнту необхідно лише передати туди параметри з допомогою методу SetXxx. Після встановлення параметрів викликається метод ExecuteQuerry або ExecuteUpdata. Приклад:

String template = “uplate empl set salary=? Where ids = ?”;

PreparedStatement stm = c.preparedStatement(template);

Float [] newsalary = {00,20,30};

Int [] ids = {124,126,130};

For (int i=0;i<3;i++){

Stm.setFloat(1,newSalary[i]);

Stm.setInt(2,ids[i]);

Stm.executeUpDate();

}

Місця для параметрів всередині шаблона позначаються символом «?». Нумерація параметрів іде від одиниці. Послідовність встановлення параметрів не грає ролі.

Пакетне виконання запитів.

Іноді бувають ситуації, коли необхідно виконати декілька SQL запитів один за одним, однак вони не являються схожими(вставити запис, видалити запис, обновити значення та інші). В таких випадках прийнято користуватись пакетним виконанням SQL запитів. Для того, щоб добавити запит до деякого пакету необхідно скористатись методом addBatch класу Statement. Наведемо приклад:

Statement st = c.createStatement();

St.addBatch(“insert into customers set salary = 100 where di = 1”);

St.addBatch(“uplate customers set salary = 200 where id=2”);

St.addBatch(“select *from n customers”);

Int [] res = st.executeBatch();

Результатом виконання методу executeBatch, який виконаний пакетний запит являється масив цілих чисел. Кожен елемент цього масиву відповідає одному рядку запиту. Значення елементів масиву можна розшифровувати наступним чином:

1. значення >=0 – виконання даного запиту було б успішним і кількість записів в таблиці, які були змінені даним запитом рівне значенню елемента масиву.

2. значення -2 – виконання успішне, але кількість записів, які були змінені даним запитом невідоме.

3. значення -3 – виконання запиту не успішне, однак при цьому виконання інших запитів пакету виконуються. Невиконання одного запиту пакета не впливає на інші.

Виклик внутрішніх процедур та функцій субд.

На сьогоднішній день надзвичайно рідко можна зустріти бази даних, які не використовують внутрішні процедури. Ці процедури зберігаються на сервері баз даних і являються частиною СУБД. В більшості випадків ці процедури пишуться на мові PL/SQL, однак найбільш потужні СУБД Oracle та MS SQL дозволяють писати ці процедури на інших мовах програмування(в основному java). Для того, щоб викликати деяку внутрішню процедуру використовується об’єкт CollableStatement. Наведемо приклад:

CallableStatement cst = c.callableStatement(“{?=call getSum(?)}”);

Cst.setInt(2,10);

Cst.regstrOutParameter(1,java.sql.Tepes.Double);

St.Execute();

System.Out.PrintLn(“Sum=”+cst.getDouble());

Слід звернути увагу на фігурні скобки ври виклику процедури. Це являється частиною синтаксису виклику. В деяких СУБД цей синтаксис може змінюватись. При роботі довільних SQL запитів з Api JDBC можуть виникати виключні ситуації. Всі виключні ситуації пов’язані з SQL розміщені в класі SQLException. Даний клас має три поля:

1. текстовий опис помилки.

2. текстовий опис стану в стандарті іховки(Xoren).

3. код помилки виробника бази даних.

Аплети

Однією з найбільших переваг мови java – це можливість створення аплетів, маленьких програм, які працюють в середині веб-браузера. Оскільки аплети виконуються на комп’ютері користувача, то на них накладається ряд обмежень:

1. аплети не мають доступу до жорсткого диску. Однак завдяки системі цифрових підписів можна визначити деякі аплети як довірені, а отже зняти більшість обмежень.

2. аплетам необхідний певний час, щоб завантажити необхідні дані з Інтернету. Зменшення завантаження атлета по мережі відбувається за рахунок використання java архівів.

В мові java існує два варіанти створення аплетів: 1) створити нащадок підкласу Applet (java.applet.Applet); 2) створити нащадка від класу japplet. Відмінність між цими двома класами полягає в тому, що перший був визначений в ранніх версіях java і не підтримував повну платформенну незалежність, вигляд GUI був не дуже вдалий. Japplet був створений в пізніших версіях java, має повну платформенно незалежність і кращій вигляд GUI. На даний момент використовують другий спосіб. На відміну від консольних додатках, які виконуються без опитування подій від користувача, аплети очікують якійсь події і змінюють свій стан у відповідності до цих дій, тобто задача аплета – «висіти» в пам‘яті і перехоплювати події користувача. В обох версіях аплетів визначено декілька методів, які призначено для функціонування аплетів. Перший метод – init, другий - start, третій - stop, четвертий - destroi

Метод init викликається тоді, коли браузер завантажує у своє вікно документ HTML з тегом applet, який посилається на певний аплет. Після завантаження атлета по мережі, здійснюється запуск методу init, який може виконувати встановлення початкових параметрів аплета, створювати початкові потоків т.і. метод init подібний до конструктора класу.

Метод start виконується після методу init. Ми можемо модифікувати код, якщо при кожному відвідуванням сторінку з аплетом, необхідно проводити ініціалізацію. Також даний метод автоматично викликається, якщо відбувається виклик вікна з аплетом (попередньо воно неактивним або згорнутим)

Метод stop служить доповненням до методу start, він одержує керування тоді, коли користувач змінює активне вікно, або робить вікно з аплетом не активним. Якщо користувач закриває вікно з аплетом, тому відбувається виклик методу stop а після нього метод destroy.

Метод destroy призначений для видалення атлета з пам‘яті. В базових класах він визначений, як порожня заглушка. Програміст може використати даний метод, коли необхідно закривати які-небуть потоки, з‘єднання т.і.

Додатковим методом, який використовується в аплетах являється метод paint. Даний метод описаний в пакеті java.awt. сам метод призначений для перемалювання області аплету. Кожного разу, коли вікно атлета перекривається іншими вікнами, робиться неактивним, а потім знову активним, його необхідно перемалювати. Також даний метод призначений для спеціалізованого виводу в області аплету.

Життєвий цикл аплету:

1. етап ініціалізації аплету (init)

2. етап старту аплету (start)

3. етап перемалювання області аплету (paint)

4. перехід в режим очікування подій користувача

5. якщо відбулась якась подія – обробка реакції на цю подію та перехід на етап 3

6. зупинка роботи аплету (stop)

7. звільнення пам‘яті (destroy)

В основному всі етапи роботи аплета вже описані нами, крім етапу обробки подій користувача. В загальному випадку в ранніх версіях java для перехоплення подій користувача використовувався метод, який називається action. Синтаксис даного методу має наступний вигляд:

Public Boolean action(Event evm, Object obj)

{

…

}

На основі аналізу об’єкта evm та obj, даний метод приймав рішення про виконання тих чи інших дій. За рахунок великої кількості операторів if відбувалась визначення що виконувати і з чим працювати. З ростом кількості елементів GUI елементів нашого аплету, збільшувався розмір даного методу. Даний метод являє собою приклад централізованої обробки подій.

В більш нових версіях використовують децентралізований спосіб обробки подій. Децентралізований спосіб будується на використанні поняття внутрішніх класів та понятті слухача подій. В цьому випадку створюють деякій внутрішній(як правило безіменний клас), який реалізує інтерфейс ActionListener. В даному інтерфейсі описаний лише один метод ActionPerformed, який призначений для отримання повідомлень про виконання певних подій над складовими аплету. При цьому кожна складова аплету повинна бути підключена до даного слухача подій з допомогою методу AddActionListener. Як правило для зменшення кількості умов та реалізації децентралізованого способу, для кожного елементу GUI інтерфейсу створюється свій власний внутрішній клас. Наведемо приклад централізованого обробника подій на основі методу ActionPerfomed:

Import java.swing.*

Import java.awt.*

Public class Demo extends jApplet

{

jButton bfn;

jtextFiled fld

ActionList act = new ActionList();

Class ActionList implements ActionListener()

{

Public void ActionPerformed(ActionEvent evn)

{

If (evn.getSource() == btn)

{

String str = fld.getText();

Bth.setText(str);

}

}

}

Public void init()

{

Btn = new jButton(“Start”);

Fld = new jTextFiled(“New text”,R);

Btn.addActionListner(act);

Fld.addActionListner(act);

Container cp = getContantPane();

Sp.setLaout(new FlowLayout());

Cp.add(btn);

Cp.add(fld);

}

}

Для добавлення графічних елементів на область аплета використовують систему менеджерів розміщень. Менеджери розміщень відповідають за розміщення компонентів в області аплету, за зміну розмірів цих елементів, зміну положення цих елементів (якщо аплет змінює свої розміри). Опишемо коротко основні менеджери розміщень:

1. FlowLayout – розміщує компоненти на тлі атлета послідовно зліва на право до тих пір, поки вони поміщаються в один рядочок, потім переходимо на наступний рядок і.т.д.

2. CridLayout – представляє вікно як таблицю n на m, де n і m вказується при створенні менеджером.

25