A web-alkalmazások fejlesztése során előbb vagy utóbb megjelennek olyan feladatok amelyeket folyamatosan végre kellene hajtani meghatározott időközönként. Ilyen feladat lehet például a hírlevelek heti egyszeri kiküldése, a keresési indexek óránkénti frissítése vagy éppen az inaktív felhasználók havi törlése. Továbbá vannak olyan taszkok is, melyeket egyetlen egyszer kell elvégezni egy adott jövőbeli időpontban.
A Quartz egy tranzakciókezelést és klaszterezést is támogató nyílt forráskódú feladat ütemező, melyet egyaránt használhatunk Java SE ill. Java EE környezetben is, akár több ezer feladat ütemezett indításához. Mivel a hivatalos oldalon egy jól használható dokumentáció és sok minta példa segíti a Quartz megismerését, ezért a mostani leírásomat inkább egy áttekintő bejegyzésnek szántam. Először következzenek a Quartz 2 által használt fogalmak.
A Quartz egy tranzakciókezelést és klaszterezést is támogató nyílt forráskódú feladat ütemező, melyet egyaránt használhatunk Java SE ill. Java EE környezetben is, akár több ezer feladat ütemezett indításához. Mivel a hivatalos oldalon egy jól használható dokumentáció és sok minta példa segíti a Quartz megismerését, ezért a mostani leírásomat inkább egy áttekintő bejegyzésnek szántam. Először következzenek a Quartz 2 által használt fogalmak.
Job
Az a feladat, amit időzítve (N-szer) vagy ütemezetten (folyamatosan) végre kívánunk hajtani. A feladat mindig egy metódus meghívása lesz, mégpedig egy olyan osztálynak az execute() metódusa, ami implementálja a Job interface-t.
JobDetail
Egy job osztályból készített definíciós példány, ami a job-ot további tulajdonságokkal egészíti ki. Ilyen tulajdonság lehet a job neve, a job csoportja vagy éppen a data objectek (JobDataMap). Egy job-ból akár több JobDetails is létrehozható eltérő névvel, csoporttal és hozzárendelt adatokkal.
JobDataMap
A JobDataMap használatával data object-eket menthetünk el bármely JobDetail-hez, melyek a Job végrehajtása során elérhetők és módosíthatók az execute() metódus JobExecutionContext paraméterének felhasználásával. A JobDataMap-be mindig szerializálható objektumokat tegyünk, és ügyeljünk az eltérő osztály verzióikból származó problémákra is. Ajánlott a standard Java osztályokat használni (pl.:String, Long).
Trigger
Egy olyan esemény, ami kiváltja (tüzelés) a job végrehajtását. A kiváltó esemény lehet N-szer (SimpleTrigger) vagy folyamatosan ismétlődő (CronTrigger).
Scheduler
A jobok és a triggerek kezelését végzi, feladata pedig a jobok végrehajtása a triggerek tüzelésekor. A feladatok ütemezéséhez először is el kell indítani egy scheduler példányt, amit Java SE környezetben a kódból, programozott módon végezhetünk el, míg Java EE platformon általában az alkalmazásszerver indulásakor valósul meg. Az ütemező kikapcsolt/szünetelt állapotában, illetve az az alkalmazás szerver leállásakor a feladatok időzített végrehajtása is szünetel.
JobStore
A JobStore feladata a scheduler, a jobok és a triggerek működéséhez szükséges információk tárolása, melyet perzisztencia szerint az alábbi típusokba sorolhatunk:
1. TerracottaJobStore
2. RamJobStore
3. JDBCJobStore
3.1. A JDBCJobStore tranzakció típusai
3.2. A JDBCJobStore klaszterezési lehetősége
JobStore
A JobStore feladata a scheduler, a jobok és a triggerek működéséhez szükséges információk tárolása, melyet perzisztencia szerint az alábbi típusokba sorolhatunk:
1. TerracottaJobStore
- Kereskedelmi termék.
- Az adatok perzisztenciáját a Terracotta szerver biztosítja.
- Klaszterezett és Nem klaszterezett módban is használható.
2. RamJobStore
- Az időzítési információk memóriában történő tárolására szolgál.
- Mivel nem perzisztens, az alkalmazás leállításával az időzítési információk elvesznek.
3. JDBCJobStore
- Az ütemezési információk tárolása perzisztens módon az erre kijelölt adatbázisban történik.
- A szerver leállás miatt lekésett triggerek újratüzelése megoldható a következő induláskor.
- A Quartz adatabázist létrehozó és inicializáló SQL szkriptek, a quartz tömörített állomány docs/dbTables/ könyvtára alatt találhatók.
3.1. A JDBCJobStore tranzakció típusai
- JobStoreTX: A tranzakciókat a Quartz maga kezeli le, így standalone vagy JTA tranzakciót nem használó alkalmazásoknál érdemes használni.
- JobStoreCMT: A menedzselt JTA tranzakcióra támaszkodik, így Enterprise környezetben ezt célszerű használni. Használatához, egy menedzselt és egy nem menedzselt datasource beállítása szükséges. A menedzselt datasource lehet lokális vagy XA típusú.
3.2. A JDBCJobStore klaszterezési lehetősége
- Minden node ugyanazt a Quartz adatbázist használja.
- A Quartz biztosítja az automatikus load balancing-ot. Bármely trigger tüzelésekor mindig csak az egyik node fogja végrehajtani a jobot.
- Fail-over biztosítása. Ha az egyik node kiesik a többi node ezt detektálja, így a félbeszakadt jobok ismételten végrehajtásra kerülnek.
A folytatásban a Quartz különböző környezetekhez való bekonfigurálását fogom ismertetni.
Regebben nagyon sok anyazast hallottam a clusterezesere. En semmi problemat nem tapasztaltam vele, de azert semmi fontosat nem biztam ra :) Engem inkab az zavar, amikor valaki a sok ideig tarto feldolgozasait egy hatterben futo quartz jobra bizza - amitol atlathatatlan lesz es a skalazhatosag is megszunik.
VálaszTörlésMi is klaszterezve használtuk a Quartz-ot és nem volt vele gond!
TörlésAz egyik banki projekt kapcsán én is találkoztam egy hosszú lefutású adatbázis update-et végző quartz job-bal, ami sajnos nem fejeződött be reggelig, így az ügyintézők a db lockolás miatt nem tudták használni az alkalmazást...