java : traitement long

Voici la conclusion d'une discussion sur les traitements longs.

En conclusion , une application externe avec une communication via JMS, ou via la BDD avec un scheduler de tache du type Quartz ... et des ejbs qui traite la logique applicative.

Si le problème est du à une grosse requête (genre un extract, ou génération de fichiers plats) , il faut envisager un script Shell appelant du PL/SQL directement.

A partir de java 5 et de java EE 6, il est possible de faire requêtes asynchrones.

grace a des EJB asynchrones, ou des ejb timer ...


Reading between the lines of your collective responses (thanks to all you who answered!), it sounds like the general recommendation is to manage the batch-processing application in some external Java wrapper application that can interact via JMS. Then we keep our internal system logic in MDBs.


So the pattern is an external Java app which responds to JMS "start batch" messages from inside our EJB system, and which sends JMS "status update" messages back into the system. Then we have (inside our EJB container) stateless session beans which handle the job-starting requests, and MDBs which handle the status update messages and which update our internal job tracking database tables. So the external app never touches the job tracking database, and only interacts via JMS; and the EJB server never directly touches the external app.


I guess on some level this is the way it would have to be, as the batch processing can't really be made part of the J2EE clustering/failover/etc. system. Oh well. I'm sorry to have to consider deploying and managing another whole application (it's nice to have the whole system inside the EJB container), but looks like it's a bullet we'll have to bite. At least JMS will enable us to keep a uniform communication structure in the system.


We're very intrigued by IBM's "asynchronous beans" research in Websphere, but we'll wait to tackle that until it's a bit more widely deployed.... (Google for "IBM asynchronous beans" -- we can really use that kind of capability, as it sounds perfect for this problem!)