Umsetzungsmöglichkeit Stapelverarbeitung

H

hispeedsurfer

Mitglied
Hallo zusammen, ich hoffe einer von euch ist Guru genug mir helfen zu können.

Ich habe folgendes Problem.
Über eine Webseite soll der User eine recht zeitintensive Datenbankabfrage starten können. Er löst also ein Methode Serverseitig aus, diese soll den Job in eine Art Stapel einfügen, ohne gleich losrechnen zu müssen, damit der Benutzer nicht warten muss und evtl von der Seite aus weitere Anfragen starten kann. Der User soll dann per Email benachrichtigt werden sobald die Abfrage fertig ist.

Meine Schwierigkeit hierbei: Wie bekomme ich es hin die Methode aufzurufen und gleich wieder dem Benutzer verfügbar zu machen. Wenn ich die Methode aufrufe ist es ja normalerweise so, dass die Webseite erst wieder geladen wird wenn die Abfrage fertig ist.

Ich weiß, anstrengende Beschreibung:confused:, aber besser bekomme ich es nicht hin.



Kann mir jemand weiterhelfen? Wäre supi.

Viele Grüße
 
Hallo,

lass die zeitintensive Abfrage einfach in einem neuen Worker-Thread ablaufen.
Schau dir doch mal den Executors/ExecutorService unter Java 5 an.
http://www.tutorials.de/forum/java/274056-fragen-threads-und-executorservice.html
http://www.tutorials.de/forum/java/276266-komplizierter-java-queue-mechanismus.html
http://www.tutorials.de/forum/java/284282-methode-nach-bestimmter-zeit-beenden.html

In Servlet Containern / Application Servern ist es in der Regel nicht erlaubt eigene Threads zu starten. Dafür bieten viele ApplicationServer Hersteller jedoch unterstützung für CommonJ über das man dann solche Aufgaben ablaufen lassen kann.

Eine andere Variante wäre hier noch JMS als (Job)Message Queue Mechanismus zu verwenden und die Arbeit von einer MessageDrivenBean ( oder einem MessageDrivenPojo) ;-)durchführen zu lassen und nach erfolgreicher Verarbeitung eine entsprechende E-Mail zu senden.

Gruß Tom
 
Mit Spring ist auch eine nette Integration von Quartz möglich. Damit kannst du z.B. eine Methode alle 10 Minuten invoken und damit eine asynchrone Verarbeitung anstoßen.

REINHAUN!
 
Hallo,

danke für eure Antworten.
@Tom
Das mit den Worker-Thread muss ich mir mal anschauen. Hört sich ganz interessant an.

@MSProductions
Ich benutze JBoss + Seam. Da gibt es die Quartz Integration inzwischen aber auch.

Meine Idee ist halt von sämtlichen Benutzern die Anfragen auf einen Stapel zu legen und diesen dann nach dem FIFO Prinzip nacheinander abzuarbeiten.


Werde nun mal schauen wie ich das mit euren Vorschlägen hinbekommen kann.
Wenn es noch Vorschläge gibt, immer her damit.


Gruß
 
hispeedsurfer hat gesagt.:
Hallo,

danke für eure Antworten.
@Tom
Das mit den Worker-Thread muss ich mir mal anschauen. Hört sich ganz interessant an.
Zum Vergrößern anklicken....
Nur für den Fall dass dus überlesen hast: Threads sind ein NoGo in Serverumgebungen. Du musst also Asynchronität über JMS, nen Timer oder eine serverspezifische Technologie lösen.
@MSProductions
Ich benutze JBoss + Seam. Da gibt es die Quartz Integration inzwischen aber auch.
Zum Vergrößern anklicken....
Warum schlägt eigentlich alle Welt immer gleich mit Kanonen auf Spatzen? ;)
Meine Idee ist halt von sämtlichen Benutzern die Anfragen auf einen Stapel zu legen und diesen dann nach dem FIFO Prinzip nacheinander abzuarbeiten.
Zum Vergrößern anklicken....
Das haben wir schon verstanden denke ich. Technisch relevant ist dabei aber, dass du das "ablegen" von der Ausführung trennen willst und damit letzteres extra anstoßen musst. Prinzipiell gibts zwei Möglichkeiten:

1. direkt asynchron Anstoßen (z.B. per JMS) - deine Ablage ist dann quasi dei Message Queue, mit all ihren vor und nachteilen
2. Synchrones ablegen und bearbeiten der Daten über nen getimten Job. Du könntest die Sachen z.B. in eine DB legen und dann über nen Quartz Job alle X Minuten nachschauen, ob gerade ein Job bearbeitet wird, wenn nicht, schaust du nach ob zu bearbeitende Jobs in der DB liegen und startest die Verarbeitung.

Wie gesagt, jede Vorgehensweise hat seine vor und Nachteile, die es anhand der Anforderungen abzuwägen gilt. Ich würde aber grundsätzlich erstmal die 2. Variante wählen, einfach weil man sich damit nicht gleich die Notwendigkeit eines MessageBrokers ins Boot holt.

Ach ja, nen Application Server braucht man für beide Szenarien nicht ;)

REINHAUN!
 
Hi MSProductions, Danke für deine Vorschläge.


Aber was meinst du denn damit?

MSProductions hat gesagt.:
Warum schlägt eigentlich alle Welt immer gleich mit Kanonen auf Spatzen? ;)
Zum Vergrößern anklicken....


Und was ist gegen eine Lösung mit JBoss AS einzuwenden. Ich will halt ne saubere Lösung. Aber ich höre mir gerne an was du für Möglichkeiten in Betracht ziehst und was du für ('größere' ,'sichere','...')Webapplikationen verwendest.

Ach ja, nen Application Server braucht man für beide Szenarien nicht
Zum Vergrößern anklicken....

Ich denke auch die 2. Variante ist ganz gut umzusetzen.


Gruß
 
Hallo,

2. Synchrones ablegen und bearbeiten der Daten über nen getimten Job. Du könntest die Sachen z.B. in eine DB legen und dann über nen Quartz Job alle X Minuten nachschauen, ob gerade ein Job bearbeitet wird, wenn nicht, schaust du nach ob zu bearbeitende Jobs in der DB liegen und startest die Verarbeitung.
Zum Vergrößern anklicken....
Na ja, die Datenbank pollen ist da aber IMHO auch nicht das gelbe vom ei ;-) Da find ich Event getriebene Architekturen schon besser.

Gruß Tom
 
Es geht nicht um "größer" oder "sicherer", schon gar nicht bei Webapplikationen. Im Gegenteil... Welche Features, die dir nur ein ApplicationServer bietet brauchst du denn für deine Anwendung? XA Transaktionen? Inbound Messaging?

Ich würde mir nie für eine Anwendung von Anfang an nen AS hinstellen. Dafür ist der Administrationsoverhead einfach zo groß. Vielmehr achte ich von Anfang an darauf, möglichst keine Dependencies zur Plattform aufzubauen, bzw. diese zumindest in einigen wenigen Klassen zu zentralisieren.

Schreibst du deine Anwendung mit EJB bist du auf Gedeih und Verderb einem EJB Container ausgeliefert. Ohne geht dann nichts mehr - kein Test, kein Betrieb. Hältst du deinen Anwendungscode Plattformneutral (wie es z.B. mit Spring möglich ist), läuft deine Anwendung auf einem Tomcat wie in nem JBoss wie in nem WebSphere usw. Viel wichtiger noch: du kannst sie ohne Container testen.
Somit schließt du dein Einsatz eines AS nicht aus, brauchst ihn aber erst ins Boot holen, wenn er nötig wird - und dich nicht unnötigerweise mit nem Haufen Overhead rumschlagen.

Zum Thema Sicherheit: hast du dich schon mal kundig gemacht, was für Dienste über den AS standardmäßig laufen? Es steckt eine gute Menge Arbeit darin, diese wegzukonfigurieren, abzuschalten o.ä. damit die Sachen keine potentiellen Sicherheitsrisiken darstellen. Es ist schon ein wenig ironisch, wie viele AS Einsatzszenarien ich bisher gesehen hab, in denen man den Wert des AS hoch gelobt hat und die Admins dann das Ding bis zum reinen Webserver runterkonfiguriert haben. ;)

Abgesehen davon frisst ein AS deutlich mehr Resourcen als z.B. ein Tomcat.

Wie gesagt, es gibt definitiv Einsatzszenarien für AS, allderings würden meiner Meinung nach 90% der Anwendungen, die momentan auf nem AS laufen auch ohne auskommen.

Thomas Darimont hat gesagt.:
Na ja, die Datenbank pollen ist da aber IMHO auch nicht das gelbe vom ei ;-) Da find ich Event getriebene Architekturen schon besser.
Zum Vergrößern anklicken....

Ich schrieb ja, "it depends". Wie oft müssen die Jobs gestartet werden? Wie lang dauert die Verarbeitung? Wieviel wissen hat mein Projektteam im Bereich JMS? Können meine Admins eine MessageQueue administrieren? Fragen über Fragen... da kann in bestimmten Fällen schon eine technisch suboptimale Lösung manchmal das Rennen machen. Eleganter und sauberer ist die JMS Variante sicherlich, das stimmt...

REINHAUN!
 
Hallo,

ich hab ja nicht gesagt, dass eine Event getriebene Architektur zwingend auf JMS basieren muss ;-)
Was auch gut funktioniert ist beispielsweise eigene ApplicationEvents über den SpringContext zu verschicken und dann über entsprechende ApplicationListener asynchron darauf zu reagieren.


Gruß Tom
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück