tomcat 7.0.42 обединяване, hibernate 4.2, mysql rock solid autoreconnect решение

Отличен въпрос. Аз се боря с този въпрос. Най-често срещаният отговор на stackoverflow е "Зависи..." за почти всеки проблем. Мразя да го казвам, но няма къде това да е по-подходящо от настройването на вашия пул за връзки. Това наистина е игра на търсене и предлагане, където вашите заявки за връзка са търсенето, а предлагането е броят на връзките, които MySQL има. Наистина се свежда до това дали основната ви грижа е да предотвратите връщането на остарели връзки от пула, или вашата грижа е да гарантирате, че MySQL не е претоварен с неактивни връзки, защото не ги убивате достатъчно бързо. Повечето хора лежат някъде по средата.

Ако наистина разбирате защо някой би избрал конфигурация на един пул за връзки, тогава повярвайте ми, ще спрете да търсите настройката "Rocket Solid", защото ще знаете, че това е като търсене в Google за бизнес план за вашия магазин; Тя се корени изцяло в това колко заявки за връзка получавате и колко постоянни връзки сте готови да предоставите. По-долу давам примери защо бихте използвали определени настройки. Позовавам се на променливи, които ще трябва да промените в тага „Ресурс“ на тага „Контекст“ на вашия файл Context.xml. Примерна пълна конфигурация може да се види най-отдолу.

Нисък трафик

В тази ситуация имате малко заявки към вашето приложение, така че има голям шанс ВСИЧКИ връзки във вашия пул от връзки да останат остарели и първата заявка от вашето приложение от остаряла връзка ще доведе до грешка. (В зависимост от драйвера на MySQL, който използвате, грешката може да обясни, че последният успешен получен пакет е надвишил настройката wait_timeout на базата данни). Така че стратегията ви за пул за връзки е да предотвратите връщането на мъртва връзка. Следните две опции имат малък страничен ефект за сайт с нисък трафик.

• Изчакайте повече, преди да прекратите връзките - Можете да направите това, като промените стойността на wait_timeout във вашата MySQL конфигурация. В работната маса на MYSQL можете лесно да намерите тази настройка под Admnin> Configuration file> Networking. За сайт с много трафик това не се препоръчва често, защото може да доведе до това, че пулът винаги се пълни с много неактивни връзки. Но не забравяйте, че това е сценарий с нисък трафик.

• Тествайте всяка връзка - Можете да направите това, като зададете testOnBorrow = true и validationQuery= "SELECT 1" . Какво ще кажете за производителността? Имате нисък трафик в тази ситуация. Тестването на всяка връзка, върната от пула, не е проблем. Всичко това означава, че допълнителна заявка ще бъде добавена към всяка MySQL транзакция, която извършвате в една връзка. На сайт с нисък трафик това наистина ли ще ви притеснява? Проблемът с връзките ви да изчезнат в пула, защото не се използват, е вашият основен фокус.

Среден трафик

• Проверявайте периодично всички връзки -Ако не искате да тествате всяка връзка всеки път, когато се използва, или да удължите времето за изчакване, тогава можете периодично да тествате всички връзки със заявка по подразбиране или персонализирана заявка по ваш избор. Например задайте validationQuery = "SELECT 1" , testWhileIdle = "true" и timeBetweenEvictionRunsMillis = "3600" или какъвто интервал искате. За много нисък трафик това определено ще изисква повече работа. Помисли за това. Ако имате 30 връзки в пула и за 1 час се обаждат само 4, тогава бихте могли лесно да проверите всичките 4 връзки при всяка заявка, като използвате предишния testOnBorrow подход с малък удар в производителността. Но ако вместо това направите подхода „Проверка на всички на всеки час“, тогава правите 30 заявки за проверка на всички връзки, когато са били използвани only4.

Висок трафик

• Прекратете неактивните връзки по-рано - Това е ситуацията, при която всички казват, че не трябва да удължавате wait_timeout и не трябва да тествате всяка връзка. Това не е идеален модел за всяка ситуация. Когато имате значителен трафик, всяка връзка в пула ще бъде използвана и действителният ви проблем ще се превърне в увеличаване на броя на наличните връзки, като същевременно съкращава продължителността на вашето wait_time така че да не прекратявате извеждането на празни връзки в DB. Ето пример за един човек, който говори за това как има до 10 000 неактивни връзки на ден за натоварен сайт, така че иска да намали wait_timeout Намаляване на чакане_timeout за натоварен сайт

Примерна конфигурация на Context.xml

<Context>   

<Resource name="jdbc/TestDB"
          auth="Container"
          type="javax.sql.DataSource"
          factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
          testWhileIdle="true"
          testOnBorrow="true"
          testOnReturn="false"
          validationQuery="SELECT 1"
          validationInterval="30000"
          timeBetweenEvictionRunsMillis="30000"
          maxActive="100"
          minIdle="10"
          maxWait="10000"
          initialSize="10"
          removeAbandonedTimeout="60"
          removeAbandoned="true"
          logAbandoned="true"
          minEvictableIdleTimeMillis="30000"
          jmxEnabled="true"
          jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
            org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
          username="root"
          password="password"
          driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/mysql"/>
</Context>

Примерна конфигурация за web.xml

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">
  <description>MySQL Test App</description>
  <resource-ref>
      <description>DB Connection</description>
      <res-ref-name>jdbc/TestDB</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
</web-app>

Документация за свойствата на Tomcat Pool за настройка на Tomcat Pool