Je dois étudier la possibilité d'intégrer des batchs sous forme d'EJB
implémentant JDO pour délocaliser ce type de traitement des SGBDR (comme
c'est le cas actuellement pour notre application) vers un serveur serveur
d'application. Cela nous permettrait d'écrire les batchs une et une seule
fois, tout en offrant la possibilité de s'interfacer avec plusieurs types de
SGBDR (Oracle, DB2, SQL Server).
Est-ce une idée intéressante ou bien complètement farfelue ?
Qu'en est-il des temps de réponses (EJB/JDO versus Batch embarqué sur la
base) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pimousse
Je dois étudier la possibilité d'intégrer des batchs sous forme d'EJB implémentant JDO pour délocaliser ce type de traitement des SGBDR (comme c'est le cas actuellement pour notre application) vers un serveur serveur d'application. Cela nous permettrait d'écrire les batchs une et une seule fois, tout en offrant la possibilité de s'interfacer avec plusieurs types de
SGBDR (Oracle, DB2, SQL Server).
Est-ce une idée intéressante ou bien complètement farfelue ?
intéressante me semble t-il .... et plutôt intelligente ;o)
Qu'en est-il des temps de réponses (EJB/JDO versus Batch embarqué sur la base) ?
je n'ai vu JDO qu'au travers de LiDO, l'implémentation de www.libelis.com.
ils ont un forum sur lequel répondent leurs développeurs ... il y a notamment eu une discussion sur la performance JDO/sans JDO, montrant que plus le nombre de données grandissait, plus LiDO prenait le pas sur l'implémentation via JDBC (de mémoire grâce à une meilleure gestion du cache). il suffit de s'inscrire (gratuit) pour y accéder.
dans mon cas, on a utilisé la version "communautaire", vu qu'elle est gratuite (mais restreinte aussi) mon problème résidait justement dans cette restriction, à savoir qu'on ne pouvait ouvrir plus de 2 connexions (persistantes) simultanées vers la bdd .. j'étais dc obligé d'ouvrir un persistentManager avant chaque (groupe de) requête(s) et de le fermer après : or c'est l'opération qui prenait le plus de temps ... dans le cadre de services web, je ne suis pas un connaisseur de Struts, mais on m'a dit qu'on pouvait se débrouiller pour ouvrir la connexion à l'arrivée de l'utilisateur et la fermer à son départ ... de tte façon le pble de 2 connexions simultanées max persite ...
si tu veux j'ai le code qqpart, je pourrais te le filer ...
A savoir aussi, qd on ferme un persistentManager, tous les objets sortis de la bdd "disparaissent", d'où la nécessité de le recopier ... A savoir encore, la prise en charge des auto_increment (mySQL) n'est pas native : mais une petite astuce de filou via la création d'une table supplémentaire permet de s'en sortir ... A savoir enfin, JDO est très mal documenté je trouve (soit rien, soit bcp trop complexe et inutile dans le cadre d'un dev), et LiDO ne fait guère mieux (3 bonnes semaines en cumulé m'ont été nécessaires pour réaliser mon implémentation à force de se perdre ds les méandres de la doc) : il faut dc ne surtout pas hésiter à utiliser le forum de Libelis.
@++ Pimousse
Je dois étudier la possibilité d'intégrer des batchs sous forme d'EJB
implémentant JDO pour délocaliser ce type de traitement des SGBDR (comme
c'est le cas actuellement pour notre application) vers un serveur serveur
d'application. Cela nous permettrait d'écrire les batchs une et une seule
fois, tout en offrant la possibilité de s'interfacer avec plusieurs types
de
SGBDR (Oracle, DB2, SQL Server).
Est-ce une idée intéressante ou bien complètement farfelue ?
intéressante me semble t-il .... et plutôt intelligente ;o)
Qu'en est-il des temps de réponses (EJB/JDO versus Batch embarqué sur la
base) ?
je n'ai vu JDO qu'au travers de LiDO, l'implémentation de www.libelis.com.
ils ont un forum sur lequel répondent leurs développeurs ...
il y a notamment eu une discussion sur la performance JDO/sans JDO, montrant
que plus le nombre de données grandissait, plus LiDO prenait le pas sur
l'implémentation via JDBC (de mémoire grâce à une meilleure gestion du
cache).
il suffit de s'inscrire (gratuit) pour y accéder.
dans mon cas, on a utilisé la version "communautaire", vu qu'elle est
gratuite (mais restreinte aussi)
mon problème résidait justement dans cette restriction, à savoir qu'on ne
pouvait ouvrir plus de 2 connexions (persistantes) simultanées vers la bdd
.. j'étais dc obligé d'ouvrir un persistentManager avant chaque (groupe de)
requête(s) et de le fermer après : or c'est l'opération qui prenait le plus
de temps ...
dans le cadre de services web, je ne suis pas un connaisseur de Struts, mais
on m'a dit qu'on pouvait se débrouiller pour ouvrir la connexion à l'arrivée
de l'utilisateur et la fermer à son départ ... de tte façon le pble de 2
connexions simultanées max persite ...
si tu veux j'ai le code qqpart, je pourrais te le filer ...
A savoir aussi, qd on ferme un persistentManager, tous les objets sortis de
la bdd "disparaissent", d'où la nécessité de le recopier ...
A savoir encore, la prise en charge des auto_increment (mySQL) n'est pas
native : mais une petite astuce de filou via la création d'une table
supplémentaire permet de s'en sortir ...
A savoir enfin, JDO est très mal documenté je trouve (soit rien, soit bcp
trop complexe et inutile dans le cadre d'un dev), et LiDO ne fait guère
mieux (3 bonnes semaines en cumulé m'ont été nécessaires pour réaliser mon
implémentation à force de se perdre ds les méandres de la doc) : il faut dc
ne surtout pas hésiter à utiliser le forum de Libelis.
Je dois étudier la possibilité d'intégrer des batchs sous forme d'EJB implémentant JDO pour délocaliser ce type de traitement des SGBDR (comme c'est le cas actuellement pour notre application) vers un serveur serveur d'application. Cela nous permettrait d'écrire les batchs une et une seule fois, tout en offrant la possibilité de s'interfacer avec plusieurs types de
SGBDR (Oracle, DB2, SQL Server).
Est-ce une idée intéressante ou bien complètement farfelue ?
intéressante me semble t-il .... et plutôt intelligente ;o)
Qu'en est-il des temps de réponses (EJB/JDO versus Batch embarqué sur la base) ?
je n'ai vu JDO qu'au travers de LiDO, l'implémentation de www.libelis.com.
ils ont un forum sur lequel répondent leurs développeurs ... il y a notamment eu une discussion sur la performance JDO/sans JDO, montrant que plus le nombre de données grandissait, plus LiDO prenait le pas sur l'implémentation via JDBC (de mémoire grâce à une meilleure gestion du cache). il suffit de s'inscrire (gratuit) pour y accéder.
dans mon cas, on a utilisé la version "communautaire", vu qu'elle est gratuite (mais restreinte aussi) mon problème résidait justement dans cette restriction, à savoir qu'on ne pouvait ouvrir plus de 2 connexions (persistantes) simultanées vers la bdd .. j'étais dc obligé d'ouvrir un persistentManager avant chaque (groupe de) requête(s) et de le fermer après : or c'est l'opération qui prenait le plus de temps ... dans le cadre de services web, je ne suis pas un connaisseur de Struts, mais on m'a dit qu'on pouvait se débrouiller pour ouvrir la connexion à l'arrivée de l'utilisateur et la fermer à son départ ... de tte façon le pble de 2 connexions simultanées max persite ...
si tu veux j'ai le code qqpart, je pourrais te le filer ...
A savoir aussi, qd on ferme un persistentManager, tous les objets sortis de la bdd "disparaissent", d'où la nécessité de le recopier ... A savoir encore, la prise en charge des auto_increment (mySQL) n'est pas native : mais une petite astuce de filou via la création d'une table supplémentaire permet de s'en sortir ... A savoir enfin, JDO est très mal documenté je trouve (soit rien, soit bcp trop complexe et inutile dans le cadre d'un dev), et LiDO ne fait guère mieux (3 bonnes semaines en cumulé m'ont été nécessaires pour réaliser mon implémentation à force de se perdre ds les méandres de la doc) : il faut dc ne surtout pas hésiter à utiliser le forum de Libelis.
