vendredi 23 décembre 2011
05:29 | 
Publié par
Jean FRANCOIS |
La Transaction permet de faire des modifications sur des systèmes de façon permanente et sécurisée assurant l’intégrité de la donnée quand aux modifications apportées (fonctionnalité importante dans le cas de système distribué sujet à incident).
C’est un mécanisme local ou distribué qui permet de garantir la réussite d’un ensemble d’opérations de façon unique. Si une des opérations échoue, c’est l’ensemble des opérations qui sont invalidées. Ces opérations peuvent s’exécuter au même endroit ou sur des ressources séparées.
Une transaction se caractérise par les principes présentés ci-dessous (ACID)
ü Atomicité Toutes les actions associées sont en succès ou en échec. Si une erreur intervient sur un élément, c’est le groupe qui est en échec et remis à l’état initial.
ü Cohérence Passage d’un système d’un état à un autre de façon cohérente.
ü Isolation Indépendance des transactions sur des interactions simultanées.
ü Durabilité Le résultat est persisté, même en cas de panne.
Les initiateurs de la transaction ou Transaction Originator u peuvent être :
ü Un client JAVA ou Bean.
ü Un client CORBA
ü Un objet RMI
ü EJB Bean Managed
ü EJB Container Managed
ü JDBC
ü JMS
ü JEE Connector
ü JSP
ü Servlet
ü Resources Externes
Chaque élément participant à une transaction est appelé Resource v (DataBase, JMS etc … ). Pour que la ressource soit transactionnelle, il lui faut un Ressource Manager w pour coordonner la communication entre la Resource et le Transaction Manager x. Ce Ressource Manager peut être implémentée dans un driver comme le cas JDBC ou directement dans la Resource comme la partie JMS de Weblogic.
Une transaction peut être Local (n’utilise pas de Transaction Manager et un seul Ressource Manager coordonnée localement) ou Distributed (plusieurs ressources de natures et de proximité différente comme DataBase et JMS coordonné par un Transaction Manager). Dans le cas où une transaction globale ne met en jeux qu’une seule ressource, une optimisation est mise en jeux et il n’y a qu’un commit d’effectué (pas de prepare).
IMPORT/EXPORT MODE
Weblogic peut être l’initiateur de la transaction. On parle alors d’export de transaction (exporting transactions) u . Il peut également participer à une transaction distribuée initiée par un composant externe (foreign transaction managers). On parle alors d’import de transaction (importing transactions) v .
Dans le cas d’import, le Transaction Manager a le rôle d’un coordonnateur de la transaction importé. Deux possibilités sont offertes pour l’import. Via une Gateway client u ou server v selon (selon l’API utilisé par le client).
InterposedTransactionManager itm = TxHelper.getClientInterposedTransactionManager(initialCtx, serverName);
InterposedTransactionManager itm = TxHelper.getServerInterposedTransactionManager();
COORDINATION
Le Transaction Manager coordonne la transaction globale et lui assigne un identifiant unique ou Xid qu’il transmet à tous les Resource Managers impliqués dans la transaction (Exemple : JTS implémentation, Weblogic Transaction Manager). Il n’y a qu’un Transaction Manager par instance Weblogic ou par Client (il n’y a qu’un Coordinateur par instance).
Le Resource Manager u coordonne les communications entre la Ressource et le Transaction Manager w dans une transaction globale. Il coordonne les communications entre la Ressource v et le serveur d’applications x lors des accès d’une transaction locale ou sans transaction (Exemple : Weblogic JTS Driver, Weblogic JMS).
Une Resource accédé via un Resource Manager par une application qui peu on non participer à une transaction (Exemple : DataBase, Persistant Messaging Store).
REGISTRATION
Une Ressource est enregistrée (Resource Registration) u dans le Transaction Manager typiquement quand une ressource démarre. Cela permet au Transaction Manager v d’être notifier que la Resource est disponible pour participer à une Transaction Global (API d’enregistrement non définit par JTA).
Pour que le Transaction Manager puisse coordonner les travaux de transaction réalisés par les Resource Manager, le serveur d’applications doit enregistrer et de-enregistrer w (enlist et delist) la ressource utilisée dans la transaction.
Le processus d'enrôlement w (enlistment) associe une ressource x à une transaction particulièrey. Cela se traduit dans le gestionnaire de transactions par un appel au gestionnaire de ressources pour commencer à associer la transaction avec le travail effectué par les ressources correspondantes.
Deux types d’enlistement :
ü Static Enlistment Le serveur d'applications inscrit automatiquement une ressource statique dans toutes les transactions qu'il gère, avant exécution de tout code applicatif (systématique).
ü Dynamic Enlistment Quand une ressource dynamique est appelé par le code applicatif dans le contexte de transaction, c’est celui-ci qui a la responsabilité de l’enlistement dans sont thread d’exécution. Ce qui à pour avantage d’avoir un « lazy enlistment » si besoin (a la demande, et non pas systématique).
API
Deux API Java permettent d’implémenter et utiliser une transaction dans un environnement JEE.
JTS (Java Transaction Service) est la couche bas niveau de gestion de service de transaction qui permet de mapper java à l’Object Transaction Service de l’OMG (Object Management Group).
JTA (Java Transaction API) est l’interfaça plus haut niveau constitué de deux parties :
ü Transaction Interface Implémentation de la transaction demarcation qui permet la constitution d’un ensemble d’opérations effectué de façon distribuée regroupée sous une même transaction.
ü XA Resource Interface Basé sur l’interface XA X/Open et permet le pilotage de transaction distribué (Two Phase Commit ou 2PC). C’est la coordination de plusieurs transactions distribuées sur plusieurs ressources distantes.
JTA fournit l’API (javax.transaction) qui définit le contrat entre le Transaction Manager et les Resources Manager, Application et Application Server (javax.transaction.xa ajoute l’enlist et delist des objets ressources dans la transaction JTA).
L’interface XA définit l’interface entre le Transaction Manager et le Resource Manager définit par l’OpenGroup Distributed Transaction Processing Model.
JTS est l’implémentation de l’interface des Transaction Manager qui se retrouve dans les driver JDBC et accès aux ressources participant à la transaction.
DEMARCATION
La Transaction Demarcation est un processus qui spécifie l’état de la transaction : started, suspended, resumed, committed, rolled back. Ces états peuvent être positionnés applicativement via JTA ou par paramétrage (via des descripteurs XML). Les démarcations automatiques sont appelées container managed transaction (utilisé dans les containers EJB). Les démarcations manuelles peuvent être réalisées via JTA sur des Servlet ou JavaBean et EJB appelé alors bean managed transaction.
Les attributs suivants définit côté EJB container managed transaction permet de définir comment les méthodes EJB vont participer à la transaction :
SUPPPORTS T1 | T1 no | no | Déclare au conteneur que la mise en œuvre peut traiter les appels, associés au contexte transactionnel ou non. Si un appel du conteneur possède un contexte transactionnel, il est utilisé. Dans le cas contraire, la mise en œuvre est effectuée sans contexte. |
REQUIRED T1 | T1 no | T2 | Déclare au conteneur que la mise en œuvre a besoin d’un contexte transactionnel. Si un bean transmet un contexte transactionnel lors de cet appel, le conteneur envoie la transaction à la mise en œuvre. Dans le cas contraire, le conteneur crée un contexte, appel begin() et valide à la fin du traitement. Required commence une nouvelle transaction enregistrée avec le TM JTA de WLS. Toutes les ressources seront enlisted dans la transaction de façon static, dynamique, ou de la façon Objet Oriented. |
REQUIRES NEW T1 | T2 no | T2 | Positionne le conteneur de manière que, quel que soit l’appel reçu, il crée une transaction, la transmette à la mise en œuvre du bean et la valide à la fin du traitement. Required New suspend la transaction en cours et en démarre une nouvelle enregistrée et managée par le TMP JTA de WLS. Quand une méthode finit la transaction avec un commits/rollsback, la précédente transaction et restauré. |
MANDATORY T1 | T1 no | Er | En cas de réception d’un rappel sans contexte, le conteneur lance une exception javax.ejb.TransactionRequiredException. |
NOT SUPPORTED T1 | no no | No | Déclare au conteneur que le bean déployée ne prend pas en charge les transactions. Il peut s’agir d’une transaction gérée par le bean. Si l’appel entrant est associé à une transaction issue de l’appelant, le conteneur ne transmet pas ce contexte à la mise en œuvre. Le contexte transactionnel n’est pas accessible via EntityContext. |
NEVER T1 | Er no | no | En cas de réception d’un appel avec contexte, le conteneur lance une exception (java.rmi.RemoteException, pas de symétrie avec MANDATORY) au client |
Le server démarre toujours les transactions de façon locale. Le client démarre la transaction localement, mais délègue la coordination, le management, le commit et le rollback au 1er serveur qu’il contacte dans la transaction.
Méthode pour le Bean Managed interface javax.transaction.UserTransaction.
ü void begin()
ü void commit()
ü int getStatus()
ü void rollback()
ü void setRollbackOnly()
ü void setTransactionTimeout(int seconds)
2PC
Two Phase Commit (ou Distributed Transaction ou XA Transaction) est un Protocol utilisé pour contrôler les transactions distribuées (implémentation Weblogic de Open Group’s XA).
Il définit les différents états et commande transitant entre le Transaction Manager initié par le Transaction Originator, et le Ressource Manager durant le cours de la transaction (divisée en deux phases). Les phases de transition étant persisté dans des Recoverable Resource (FileStore ou DataBase).
ü Dans la 1er phase du processus de commit, une mise à jour des données et actions est sauvegardée dans un log de transaction. Il est alors demandé à chaque ressource s’ils peuvent garantir le succès de leurs parts de transaction (ou Transaction Branch).
ü La seconde phase du processus dépend des résultats de la 1er. Si toutes les ressources répondent positivement, le transaction manager donne l’ordre à tous les ressources manager de commiter leurs branche de transaction, et les modifications apportées à la transaction sont porté définitivement sur toutes les ressources participantes. Par contre, si une des ressources est en échec sur sa branche, une notification est donnée à toutes les ressources d’effectuer un roll back.
Les autres conditions d’un Rollback peuvent être :
ü Un timeout de transaction.
ü L’application maque la transaction en Rollback Only.
ü L’application requête explicitement le Rollback de la transaction.
Seul le Transaction Manager qui a initié la transaction à la possibilité d’effectuer le commit ou rollback (transaction owner).
BRANCHE DE TRANSACTION
Une transaction globale possède une ou plusieurs banches de transactions (Transaction Branch). Tous les travaux uniques des Ressources Managers font parties d’une Banche.
Chaque identificateur de transaction de branche (XID), que le gestionnaire de transactions donne au gestionnaire de ressources, identifie à la fois une transaction globale et une branche spécifique.
Quand une transaction implique par exemple, une DataBase et une File JMS, chaque élément pré sité représente une branche.
TRANSACTION SCOPE
Weblogic support des transactions sur :
ü Un server simple.
ü Entre deux server non clusterisé.
ü Entre deux clusters d’un même domaine.
ü Entre deux domaines.
Pour propager la transaction inter domaine, il faudra paramétrer les domaines avec les recommandations de la documentation : Configuring Domains for Inter-Domain Transactions.
La principale contrainte est d’avoir des ressources de nom unique entre domaines (nom du domaine, server, non des Datasource, etc … ). Dans le cas des ressources, on peut conserver le même nom, si elle adresse la même ressource (même nom JDBC pour deux DataSources sur deux domaines différents, mais pointant sur une même DataBase).
COORDINATOR / SUB COORDINATOR
Coordinator : Objet associé à une transaction qui fournit des opérations nécessaire à la ressource afin de participer à la transaction (récupération du status de la transaction, enregistrer un ressource pour participer à une transaction, récupérer le contexte de transaction). Chaque transaction est associée à un Coordinator. Un objet coordinateur par instance.
SubCoordinator : System d’objet (un par server) responsable de la surveillance de l’état et de la détection de toutes les branches active sur le serveur.
XID
Le Xid définit de façon unique une transaction et contient (Java mapping de la spécification de transaction de la structure XID) :
ü format identifier
ü global transaction identifier (64 bytes maximum)
ü branch qualifier (64 bytes maximum)
Exemple des informations visibles issues de l’extraction d’un TLOG (visible d’un debug JTA).
Class Name = weblogic.transaction.internal.ServerTransactionImpl | Object = Xid=BEA1-032DAA190B8A7F28EDB9(12864392),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=4851,seconds left=30,XAServerResourceInfo[JMS_FileStore]=(ServerResourceInfo[JMS_FileStore]=(state=new,assigned=none),xar=null),XAServerResourceInfo[XAPool]=(ServerResourceInfo[XAPool]=(state=new,assigned=none),xar=null))
Classe d’implémentation d’une transaction côté server. |
Class Name = weblogic.transaction.internal.ServerTransactionImpl |
Objet d’état de transaction. |
Object = |
Identifiant global de transaction (le numéro entre parenthèses est le hash code de l’identifiant de l’objet de transaction qui ne fait pas parti du Xid). |
Xid=BEA1-032DAA190B8A7F28EDB9(12864392), |
Statuts global de la transaction |
Status=Active, |
Nombre de réponses du SubCoordinator que la transaction globale attend. |
numRepliesOwedMe=0, |
Nombre de réponses que cette transaction possède d’un coordinateur supérieur. |
numRepliesOwedOthers=0, |
Nombre de secondes depuis que la transaction globale a commencé. |
seconds since begin=4851, |
Time to Live en seconds. Seconde qui reste avant de considérer la transaction en Timeout. |
seconds left=30, |
Le XAResourceInfoobject qui encapsule le XAResourceinformation associé à une transaction globale. Information maintenue dans un état per-transaction. |
XAServerResourceInfo[JMS_FileStore]=(ServerResourceInfo[JMS_FileStore]= (state=new,assigned=none),xar=null), |
XAServerResourceInfo[XAPool]=(ServerResourceInfo[XAPool]=(state=new,assigned=none) ,xar=null)) |
Exception remontée possible :
ü HeuristicCommitException
ü HeuristicMixedException
ü HeuristicRollbackException
ü InvalidTransactionException
ü NotSupportedException
ü RollbackException
ü SystemException
ü TransactionRequiredException
ü TransactionRolledBackException
Statuts global de la transaction | |
STATUS | Signification |
STATUS_ACTIVE | Status code indicating an active transaction |
STATUS_MARKED_ROLLBACK | Status code indicating a transaction that has been marked for rollback only |
STATUS_PREPARED | Status code indicating a transaction that has been committed. Probably heuristics still exists, or the transaction would no longer exist. |
STATUS_COMMITTED | Status code indicating a transaction that has been committed. Probably heuristics still exists, or the transaction would no longer exist. |
STATUS_ROLLEDBACK | Status code indicating a transaction that has been rolled back. Probably heuristics still exists, or the transaction would no longer exist. |
STATUS_UNKNOWN | Status code indicating that the transaction status could not be determined. |
STATUS_NO_TRANSACTION | Status code indicating that no transaction exists. |
STATUS_PREPARING | Status code indicating a transaction that has begun the first phase of the two-phase commit protocol, not not yet completed this phase. |
STATUS_COMMITTING | Status code indicating a transaction that has begun the second phase of the two-phase commit protocol, but not yet completed this phase. |
STATUS_ROLLING_BACK | Status code indicating a transaction that is in the process of rolling back. |
Heuristic Decision (completion)
Interviens quand une ressource effectue une décision unilatérale dans la phase d’achèvement de la transaction dans le cas d’incident (rupture réseau, timeout). Cela peut laisser des données dans un état indéterminé, car la décision peut être erronée par rapport à l’incident (commit alors que la donné n’a pas été modifier, etc … ). Quand cela intervient, un log de notification est déclenché.
L'attribut ForgetHeuristicsJTA détermine si oui ou non le gestionnaire de transactions effectue automatiquement une opération de XAResource.forget() pour toutes les ressources reportant une décision heuristique. La valeur par défaut est true.
Réglez-le à false uniquement si vous savez quoi faire avec la ressource quand il rapporte une décision heuristique.
Dans le cas d'une Completion Heuristique, l'une des exceptions heuristiques suivantes peut être jetée (pour indiquer quel type d’incohérence peut être attendu) :
ü HeuristicRollback Décision autonome d’un RM de roolbacker indépendamment de l’ordre de commit du TM.
ü HeuristicCommit Inverse de HeuristicRollback
ü HeuristicMixed TM informé d’un résultat mixte de branche en commit et rollback (HeuristicRollback ou HeuristicCommit de certaines banches).
ü HeuristicHazard Même chose que HeuristicCommit mais sans en avoir la certitude (due à une défaillance technique).
GLOSSAIRE
JTA (Java Transaction API) | Spécification qui permet à JAVA de réaliser des transactions distribuées via les Transaction Manager. |
JTS (Java Transaction Service) | Spécifie l’implémentation JAVA qui supporte la spécification JTA. |
XA | Spécification qui définit les interfaces entre le Transaction Manager (TM) et les Ressources Managers (RM) |
LOCAL TRANSACTION | Des transactions qui impliquent une ressource et un Ressource Manager (RM) non géré par un Transaction Manager (TM). Elles sont démarrées et coordonnées de façon interne par le RM. L’interface XA n’est donc pas utilisée. Par exemple, une transaction dans une DataBase. |
GLOBALE TRANSACTION | Une transaction coordonnée par un Transaction Manager impliquant plusieurs ressources et plusieurs Ressources Managers. Les synonymes sont Distributed Transaction, XA Transaction, Two-Phase Commit. Par exemple une transaction mettant en jeux une base et des opérations JMS, deux Database différentes ou une transaction initiée par un container EJB. |
TRANSACTION MANAGER | Objet singleton qui gère l’état de vie de la transaction sur ces différentes phases (start/commits/rollbacks). Il affecte un identifiant unique aux transactions globales (Xid), et coordonne celle-ci. Lors des commit ou rollback, il communique l’information à chacun des Ressources Manager impliqués dans la transaction. Exemple JTS ou Weblogic Transaction Manager implémentation |
RESSOURCE MANAGER | Coordonne les communications entre la ressource et le TM quand il est accède via une transaction globale. Coordonne les communications entre la ressource et l’application quand il est accédé dans le cadre d’une transaction locale ou sans transaction. Exemple Weblogic JTS Driver ou JMS. |
RESSOURCE | Fournis des opérations qui peuvent être invoquées par le Service de transaction, qui permettent à la ressource d’effectuer une transaction Par exemple: -Exécuter la phase de préparation du two-phase commit -Valider la transaction -Restauration de la transaction |
PESSIMISTIC TRANSACTION | Générant un lock sur des données utilisées, prévenant de l’utilisation de ces données sur des transactions concurrentes. Cela évite des conflits entre transactions, mais consume de la ressource. |
OPTIMISTIC TRANSACTION | Consume moins les ressources que les transactions Pessimistic car n’utilise pas de lock. Deux transactions peuvent donc mettre à jour une même donnée en même temps. Le conflit sera détecter seulement que dans la seconde phase de la transaction de commit ou flush (qui entrainera un rollback) |
RESOURCE | Accédé via le Resource Manager par l’application. Peut participer à une transaction ou non. Exemple DataBase ou Persistent Store. |
RecoveryCoordinator | Utilisé par une ressource pour conduire le processus de récupération des transactions |
Current | Simplifie le codage en fournissant un accès à un contexte de transaction par thread implicites |
RESOURCE REGISTRATION | Une ressource s’enregistre dans un TM Weblogic (principalement au démarrage de celle-ci). Cela permet d’informer au TM de la disponibilité de la ressource à participer à une Transaction globale. Non défini dans la spécification, mais implémenté par Weblogic. |
XA RESSOURCE | Un objet de transaction XA qui prend part à une transaction et qui peut être persisté. Exemple Queuing, Database. C’est une interface standard donnant au système transactionnel un contrôle sur le RM. Une ressource est enregistrée dans un TM au démarrage (TM.registerResources). A chaque utilisation de la ressource par une transaction, celle-ci est enregistrée dans le thread courant de transaction (Enlisted) |
In-Doubt Transaction | Dans le cas de disfonctionnement sur le TM, les transactions sur le RM son en In-Doubt et peuvent provoquer des locks sur les données. Tant que la transaction n’a pas été commite ou roolbacker, les données en lock ne peuvent être accéder par d’autres ressources. |
XAResourceManager | Objet Manager singleton qui contrôle toutes les interfaces avec les ressources. |
ResourceDescriptor | Description Weblogic de la ressource définissant sont type, sont identité et sa configuration. |
ResourceInfo Object | Objet représentatif de la ressource dans une transaction individuelle. |
TransactionFactory | Utilisé par l’investigateur de la création de la transaction (originator). Retourne un objet Control. |
TransactionLogger | Un objet par instance Weblogic. Chargé de contrôler l’écriture des enregistrements de transactions sur le disque, au nom du coordonnateur. Lit les enregistrements des transactions à partir du disque pour recréer les objets de transaction pendant le processus de récupération des transactions. |
TransactionService | Un objet par WebLogic Server. Cette classe implémente des événements du cycle de vie du service de transaction. Il reçoit les événements de cycle de vie du framework de WebLogic Server. Lors de l'initialisation du serveur, il démarre le gestionnaire de transactions et le coordonnateur local, et les lie dans JNDI. |
TransactionRecoveryService | Un objet par WebLogic Server. Si dans un environnement en cluster, un objet actif par WebLogic Cluster. Cette classe implémente la récupération des transactions à la fois pour le serveur local et d'autres serveurs dans le même cluster, le cas échéant. Il implémente le contrat « Migratable Service » tel que défini par le cadre cluster. |
Control | Objet associé à une transaction. Utilisé pour manipuler un participant à la transaction. Permet de d’accéder à un Terminator ou un Coordinator. |
Terminator | Objet qui fournit des opérations pour finir la transaction via des Commit/Roolback. |
Coordinator | Objet associé à une transaction qui fournit des opérations nécessaire à la ressource afin de participer à la transaction (récupération du status de la transaction, enregistrer un ressource pour participer à une transaction, récupérer le contexte de transaction). Chaque transaction est associée à un Coordinator. Un objet Coordinateur par instance. |
SubCoodinator | System d’objet (un par server) responsable de la surveillance de l’état et de la détection de toutes les branches active sur le serveur. |
XID (XA Transaction ID ) | Identifiant unique de la transaction contenant identifieur, un identifieur de transaction globale (64 bits) et un qualifieur de branche (64 bits). |
TRANSACTION BRANCH | Une transaction globale a une ou plusieurs Transaction Branch. Chaque unité d’exécution (unit of work) d’un Ressource Manager participant à la transaction globale est représentée par une branche. Chaque identifiant de branche de transaction (Xid) donné par le TM au RM identifie à la foi la transaction globale et la branche. |
RESOURCE ENLISTMENT | Afin que le TM puisse coordonner les travaux de transaction par les RM, le serveur d’applications doit enregistrer ou d’enregistrer les ressources utilisées dans la transaction (ENLIST/DELIST). Trois types possibles : Static, Dynamic, Object Oriented. |
DELISTMENT | Processus inverse d’ENLIST |
Heuristic Decision (completion) | Intervient quand une ressource effectue une décision unilatérale dans la phase de d’achèvement de la transaction dans le cas d’incident (rupture réseau, timeout). Cela peut laisser des données dans un état indéterminé, car la décision peut être erronée par rapport à l’incident (commit alors que la donné n’a pas été modifié, etc … ). Quand cela intervient, un log de notification est déclenché. |
HeuristicRollback | Décision autonome d’un RM de roolbacker indépendamment de l’ordre de commit du TM. |
HeuristicCommit | Inverse de HeuristicRollback. |
HeuristicMixed | TM informé d’un résultat mixte de branche en commit et rollback (HeuristicRollback ou HeuristicCommit de certaines banches). |
HeuristicHazard | Même chose que HeuristicCommit mais sans en avoir la certitude. |
Dirty read | Se produit quand une opération est autorisée à lire les données affectées par une autre transaction avant que celle-ci soit validée. |
Non−repeatable read | Se produit quand une transaction tente de sélectionner deux fois une même ligne, supprimé ou modifié par une autre transaction au même moment de la seconde lecture. |
Phantom read | Se produit quand une transaction lits un ensemble de ligne qui répond à un certain critère durant une autre transaction qui insère un nouvel élément sur ce même critère. |
Synchronization | Synchronization callback methods may be registered with a transaction, and are invoked just before/after commit. A typical use is to synchronize an object’s in-memory state with permanent storage. |
Abandonment | The Transaction Manager will abandon attempts to drive a transaction to a consistent commit/rollback state after a certain period of time that is configurable (default 24 hours), allowing memory to be reclaimed. Abandonment causes a heuristic hazard situation. |
Libellés :
Inscription à :
Publier les commentaires (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
2 commentaires:
un mot: Excellent!
TRANSACTION is hard task in wls.But you simplified it with awesome tutorial and with beautiful images.I love reading your posts.your posts are references for my weblogic admin training online to do practical tasks.
Enregistrer un commentaire