Affichage des articles dont le libellé est JDBC. Afficher tous les articles
Affichage des articles dont le libellé est JDBC. Afficher tous les articles
jeudi 15 novembre 2012
13:40 | 
Publié par
Jean FRANCOIS |
Enfin un mariage consommé entre BEA Weblogic et Oracle Database. Le nouveau
driver GridLink est un substitue du MultiDataSource pour se connecter à une DataBase Oracle en RAC (Real Application Clusters).
L’objectif étant d’utiliser les internes de la DataBase pour mieux coller à son architecture. Ce
driver va plus loin est rend caduque tous les palliatifs de détection d’absence
de ressource distante qui dégrade les performances du serveur d’application. Les avantages par rapport au MultiPool sont :
ü Éliminer les tests de vérification de
présence de base qui charge inutilement l’infrastructure (remonté de
notification lors d’incident directement plutôt que test systématique de la
connexion).
ü Éliminer le polling pour être notifié d’une remontée d’un
nœud DataBase.
ü Cache l’infrastructure sous-jacente de la DataBase (Ajout ou suppression dynamique de nœud RAC sans modification de configuration Weblogic).
ü Répartition de charge intelligente
fonction de la charge des nœuds RAC
(plutôt qu’un RoundRobine).
ü Notification immédiate d’incident lors de
perte sans devoir attendre de TIMEOUT (plus de perte de temps côté application).
ü Conservation de la connexion sur une même
transaction initiée par Weblogic (implémenté côté driver et non plus dans Weblogic) (non supporté en MultiDataSource dans le cas d’une transaction globale).
ü Répartition sur les instances RAC lors de la création des connexions (un
seul pool, plusieurs connexions différentes).
PRINCIPES
La différence du GridLink par rapport au MultiDataSource est qu’il n’utilise qu’un seul DataSource. Le MultiDataSource est obligé de déclarer autant de pool que d’instance RAC.
Ce driver utilise UCP (Universal Connection Pool) pour l’implémentation du pool et ses
fonctionnalités de FCF (Fast Connection Failover) via les notifications d’événement FAN (Fast Application
Notification). Cela permet de :
ü Annuler et supprimer des connexions non
valides.
ü Arrêt transparent planifier ou non
d’instance DataBase.
ü S'adapter aux changements de topologie,
tels que l'ajout ou la suppression d'un nœud.
ü Distribution dynamique des requetâge selon
la charge DataBase.
C’est la partie ONS (Oracle Notification Service) qui notifie le client de tout changement dans
l’architecture RAC (tombé
volontaire ou non de nœud, ajout ou suppression de nœud, indication de stress
des nœuds). Cela permet au GridLink d’adapter la charger et les connexions dynamiquement à l’état du cluster RAC et rendre transparent tout changement
d’architecture.
Ci-dessous un extrait de documentation qui explique comment sont gérées les
connexions lors de mouvement de nœuds RAC.
Planned down Event
Planned
outages are defined as database maintenance or other activities that are needed
to perform at a known point in time. Support for these events is available
where an Oracle RAC service can be gracefully shutdown. In such scenarios, any
borrowed or inuse connections are not interrupted and closed until work is
completed and control of the connection is returned to the pool. This provides
an extremely efficient way in large heterogeneous customer environments to
manage planned outages.
Unplanned down Event
Support
for unplanned outages is provided by detecting and removing stale connections
to an Oracle RAC cluster. Stale connections include connections that do not
have a service available on any instance in an Oracle RAC cluster due to
service-down and nodedown events. Borrowed connections and available
connections that are stale are detected, and their network connection is
severed before removing them from the pool. These removed connections are not
replaced by the pool. Instead, the application must retry connections before performing
any work with a connection. The primary difference between unplanned and
planned shutdown scenarios is how borrowed connections are handled. Stale
connections that are idle in the pool (not borrowed) are removed in the same
manner as the unplanned shutdown scenario.
Up Event
Oracle
RAC Instance Rejoin and New Instance Scenarios -Scenarios where an Oracle RAC
cluster adds instances that provide a service of interest are supported. The
instance may be new to the cluster or may have been restarted after a down
event. In both cases, WebLogic Connection Pool for JDBC recognizes the new
instance and creates connections to the node as required
LOAD BALANCING
Ci dessous un extrait de documentation qui explique comment et géré
l’attribution de connexion
Load Balancing
• Manages pooled connections for high
performance and scalability
• Receives continuous recommendations on the
percentage of work to route to database instances
• Adjusts distribution of work based on
different back-end node capacities such as CPU capacity or response time
• Reacts quickly to changes in cluster
reconfiguration, application workload, overworked nodes, or hangs
• Receives metrics from the Oracle RAC Load
Balance Advisory. Connections to well performing instances are used most often.
New and unused connections to under-performing instances will gravitate away
over time. When distribution metrics are not received, connection is selected using
a random choice
Connection Affinity
Connection
affinity allows a connection pool to select connections that are directed at a
specific Oracle RAC instance to provide the best performance for the customer
applications. The pool uses run-time connection load balancing to select an
Oracle RAC instance to create the first connection and then subsequent
connections are created with an affinity to the same instance.
Transaction-Based Affinity
Transaction-based affinity is an affinity to an Oracle RAC instance that can be released by either the client application or a failure event. Applications typically use this type of affinity when long-lived affinity to an Oracle RAC instance is desired or when the cost (in terms of performance) of being redirected to a new Oracle RAC instance is high. WebLogic XA connections that are enlisted in a distributed transaction keep an affinity to the Oracle RAC instance for the duration of the transaction. In this case, an application would incur a significant performance cost if a connection is redirect to a different Oracle RAC instance during the distributed transaction.
The affinity will be established based on the global transaction id, instead of by individual data source, to ensure that connections obtained from different data sources that are configured for the same RAC cluster are all associated with the same RAC instance. The LLR two-phase commit optimization will be supported by the RAC data source and will also participate in XA affinity.
The Universal Connection Pool Java library
has
been integrated with WebLogic Server and been utilized by WebLogic GridLink
data source implementation to provide the Fast Connection Failover, Runtime
Connection Load Balancing and Affinity features
Oracle Database services (services)
are
logical abstractions for managing workloads in Oracle Database. Services divide
workloads into logically disjoint groupings.
Each service represents a workload with common attributes, service-level
thresholds, and priorities. Services are
built into the Oracle Database, providing a single system image for workloads,
prioritization for workloads, performance measures for real transactions, and
alerts and actions when performance goals are violated. Services enable
database administrators to configure a workload, administer it, enable/disable
it, and measure workload as a single entity.
PARAMETRAGE
Le fait de créer un DataSource de type GridLink avec le FAN active, désactive complètement les tests
de validité de connexion (Test Connections On Reserve, Test Frequency) et de pooling (Connection
Creation Retry Frequency).
Ces paramètres peuvent être réactivés en désactivant le FAN.
Création d’un DataSource de type GridLink.
On spécifie l’URL SCAN d’accès aux instances RAC.
Test de connexion en succès.
Spécification des instances ONS de
notification avec les notifications FAN. On pourra spécifier ces certificats pour sécuriser les connexions avec
les ONS Wallet.
Test de connexion en succès.
VALIDATION
Pour vérifier le bon fonctionnement de l’infrastructure mis en place, vous
pouvez utiliser une petite application (gridlank_ha.war) qui démontre la répartition de charge
des connexions.
Libellés :
dimanche 28 mars 2010
Le pool JDBC ou DataSource permet de déclarer des ressources d’accès à la base prête à l’emploi, sans attendre la phase de connexion et de déconnexion réseau (objectif de performance).
Il a également la responsabilité d’assurer le service d’accès en cas de panne ou dysfonctionnement (détection de panne et reprise de service automatique) et de rendre transparent la mis en place d’une architecture cluster.
C’est donc un connecteur vital pour l’application à paramétrer correctement sous peine de défaillance grave pour la plate-forme.
Prendre le driver JDBC fourni dans la distribution de l’éditeur de base de données afin de s’assurer de la bonne version (sauf préconisation contraire du support Oracle [souvent une version de driver supérieur] ).
Placer les JAR driver dans le CLASSPATH du scripte de démarrage des instances (avant les JAR Weblogic) afin de surcharge les drivers présents dans la distribution Oracle.
(Driver type 4)
ARCHITECTURE
Plusieurs architectures sont possibles pour accéder à la base, le plus simple étant un accès direct à une instance unique. On peut avoir des pools dédiés fonction de l’utilisation, ou des pools multiples dans le cas de redondance ou de cluster DataBase. L’accès pouvant être réalisé en direct ou réparti.
Connexion
ü UNIQUE Une datasource, une instance de base.
ü TYPE Une datasource par type de requêtage (lecture/écriture/transaction).
ü MULTIPOOL Plusieurs datasource en répartition.
Accès
ü DIRECTE Accès direct à l’instance.
ü LOAD BALANCING Une répartition de la charge sur plusieurs instances.
ü FAILE OVER Une bascule en cas de problème, avec un retour éventuel en cas de reprise.
· UNIQUE
L’accès le plus simple est une datasource pour une database. Toutes les requêtes passent par un même pool.
· TYPE
Les pools typés peuvent être utilisés selon des critères de requêtage. Il faudra prévoir dans le code applicatif la datasource associée au type de requête que l’on veut exécuter.
Cela permet de dissocier les flux et le type de fréquentation sur les pools (la lecture étant sauvant plus rapide que l’écriture ou le besoin transactionnel, donc des tailles différentes)
· MULTIPOOL
Le multipool permet de déclarer plusieurs datasource sur des databases différentes ou clusterisées avec un accès centralisé. Cela permet de mieux répartir la charge ou d’assurer une tolérance aux pannes.
Ce mécanisme peut également être assuré par le driver, ou le mécanisme de répartition est décalé côté database.
· DIRECTE
L’accès pouvant être direct, mais sans tolérance aux pannes. La reprise étant assurée automatiquement.
· LOAD BALANCING
Dans le cas d’un load balancing, la répartition de charge est assurée automatiquement. Lors de la tombée d’une instance, le faile over permet de conserver la continuité de service, avec une reprise automatique.
· FAILE OVER
Dans le cas d’une connexion en faile over, c’est la même instance qui est requêtée. En cas de panne, il y a bascule vers l’instance de backup, et en remontée de service il y a faile back pour revenir sur le nœud d’origine.
POOL CONNEXION
Le pool de connexion peut être dimensionné selon les besoins de charge avec des options de contrôle de validité de connexion afin de garantir le service. Le paramétrage peut être différent selon l’architecture mise en place et les cas d’usages.
Faire attention au nombre d’instances déclarées, car les pools déployés sur ces instances ont un facteur multiplicateur.
capacité maximum du pool * nombre de pool * nombre d’instance < capacité de connexion à la base
· Capacity Maximum
La taille maximum que peut atteindre le pool.
Pour déterminer la valeur, effectuer un test de charge en désactivant l’option Allow Shrinking et en positionnant le paramètre initial à 1 et Maximum au maximum. Après le test de charge, vérifier la valeur atteinte du pool (qui représente le maximum du test de charge). Prendre cette valeur +30% comme valeur maximum.
Mettre cette valeur en concordance avec le nombre de thread si on n’utilise pas le pool dynamique de threads (version 8.1 : en théorie, un thread pour une connexion. Attention, dans certains cas (transaction, développement spécifique) il se peut qu’il y ait plusieurs connexions pour un thread actif).
On pourra effectuer un paramétrage via le WorkManager pour attribuer autant de threads que de connexion associée au pool JDBC.
max-threads-constraint Taille maximum de nombre de thread à utiliser (Default : -1). (On peut associer la valeur de la contrainte à un pool JDBC Œ. Si la valeur du pool JDBC changer, cela affectera directement la valeur de la contrainte).
· Capacity Initial
La valeur minimale générée lors de la création du pool. Si l’option Allow Shrinking est activée le pool décrémente les connexions crée en plus pour revenir à la valeur minimale.
ü Prendre la même valeur que Maximum pour obtenir une réponse optimale (pas de perte de temps sur la création d’une connexion JDBC).
ü Dans le cas où le nombre de pool et de connexions associées est supérieur à la capacité maximale de connexion de la base, on pourra utiliser l’option de décrément avec une valeur minimale de pool inférieure aux maxima. Dans le cas de charges sur des plages de temps différentes selon les instances, le nombre de connexions sera lissé naturellement en incrémentant les pools en charge et en décrémentant les pools après la charge.
ü Si on souhaite optimiser le nombre de connexions à la charge, on pourra adopter un paramétrage de type Water Mark. Il suffit de déclarer un minimum à 1 et un maximum défini par les bench et de désactiver l’option de décrément. De cette façon, la valeur sera maintenue au plus haut de la charge de façon automatique. L’inconvénient étant que cette valeur est réinitialisée à chaque redémarrage de l’instance.
· Incrément
Le pas d’incrément
À positionner quand la valeur minimale est différente du maxima.
· Allow Shrinking
L’option de décrément après une charge.
À positionner selon le cas d’usage et si le minima est différent du maxima.
· Enable Connection Leak Profiling
Option à coche (malgré le surcoût de charge que cela induit) pour remonter toutes les connexions JDBC non relâchées par l’application.
· Test Frequency
Préférer ce mode dans le cas d’une plate-forme de production. Elle permet d’effectuer un test sur le pool tous les n secondes (prendre 5 minutes). Cela permet également de s’assurer de la validité des connexions dans le cas ou un il y a un firewall entre l’instance Weblogic et la base.
· Test Reserved/Created Connections/ Released Connection
Évité ces options, car elle impose un requêtage sur chaque action utilisateur (1 requête utilisateur + 1 requête de test)
INDISPONIBILITE
Voir la documentation pour les paramètres suivants :
ü Connection Creation Retry Frequency
ü Inactive Connection Timeout
ü Maximum Waiting for Connection
ü Maximum Connections Made Unavailable
Statement Cache Size
Extraction de la documentation de tuning Weblogic
Increasing Performance with the Prepared
Statement Cache
For each connection pool that you create in WebLogic Server, you can specify a prepared statement cache size. When you set the prepared statement cache size, WebLogic Server stores each prepared statement used in applications and EJBs until it reaches the number of prepared statements that you specify. For example, if you set the prepared statement cache size to 10, WebLogic Server will store the first 10 prepared statements called by applications or EJBs. When an application or EJB calls any of the prepared statements stored in the cache, WebLogic Server reuses the statement stored in the cache. Reusing prepared statements eliminates the need for parsing statements in the database, which reduces CPU usage on the databasemachine, improving performance for the current statement and leaving CPU cycles for other tasks.
The default value for prepared statement cache size is 0. You can use the following methods to set the prepared statement cache size for a connection pool:
! Using the Administration Console. See Creating and Configuring a JDBC Connection Pool in the Administration Console Online Help at
! Using the WebLogic management API. See the getPreparedStatementCacheSize() and
setPreparedStatementCacheSize(int cacheSize) methods in the Javadocs for WebLogic Classes at
! Directly in the configuration file (typically config.xml). To set the prepared statement cache size for a connection pool using the configuration file, before starting the server, open the config.xml file in an editor, then add an entry for the PreparedStatementCacheSize attribute in the JDBCConnectionPool tag. For example:
DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
InitialCapacity="5" MaxCapacity="20" Name="demoPool"
Password="{3DES}ANfMduXgaaGMeS8+CR1xoA=="
PreparedStatementCacheSize="20" Properties="user=examples"
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="examplesServer"
TestConnectionsOnRelease="false"
TestConnectionsOnReserve="false"
URL="jdbc:pointbase:server://localhost/demo"/>
Usage Restrictions for the Prepared Statement Cache
Using the prepared statement cache can dramatically increase performance, but you must consider its limitations before you decide to use it. Please note the following restrictions when using the prepared statement cache. There may be other issues related to caching prepared statements that are not listed here. If you see errors in your system related to prepared statements, you should set the prepared statement cache size to 0, which turns off prepared statement caching, to test if the problem is caused by caching prepared statements.
Calling a Stored Prepared Statement After a Database Change May Cause
Errors
Prepared statements stored in the cache refer to specific database objects at the time the prepared statement is cached. If you perform any DDL (data definition language) operations on database objects referenced in prepared statements stored in the cache, the statements will fail the next time you run them. For example, if you cache a statement such as select * from emp and then drop and recreate the emp table, the next time you run the cached statement, the statement will fail because the exact emp table that existed when the statement was prepared, no longer exists. Likewise, prepared statements are bound to the data type for each column in a table in
the database at the time the prepared statement is cached. If you add, delete, or rearrange columns in a table, prepared statements stored in the cache are likely to fail when run again.
Using setNull In a Prepared Statement
When using the WebLogic jDriver for Oracle to connect to the database, if you cache a prepared statement that uses a setNull bind variable, you must set the variable to the proper data type. If you use a generic data type, as in the following example, the statement will fail when it runs with a value other than null.
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
Instead, use the following:
if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)
This issue occurs consistently when using the WebLogic jDriver for Oracle. It may occur when using other JDBC drivers.
Prepared Statements in the Cache May Reserve Database Cursors
WhenWebLogic Server caches a prepared statement, the prepared statementmay open a cursor in the database. If you cache too many statements, you may exceed the limit of open cursors for a connection. To avoid exceeding the limit of open cursors for a connection, you can change the limit in your database management system or you can reduce the prepared statement cache size for the connection pool.
Determining the Proper Prepared Statement Cache Size
To determine the optimum setting for the prepared statement cache size, you can emulate your server workload in your development environment and then run the Oracle statspack script. In the output from the script, look at the number of parses per second. As you increase the prepared statement cache size, the number of parses per second should decrease. Incrementally increase the prepared statement cache size until the number or parses per second no longer decreases. Note: Consider the usage restrictions for the prepared statement cache before you decide to use it in your production environment. See “Usage Restrictions for the Prepared Statement Cache” on page 8-38 for more information.
Using a Startup Class to Load the Prepared Statement
Cache
To make the best use of the prepared statement cache and to get the best performance, you may want to create a startup class that calls each of the prepared statements that you want to store in the prepared statement cache. WebLogic Server caches prepared statements in the order that they are used and stops caching statements when it reaches the prepared statement cache size limit. By creating a startup class that calls the prepared statements that you want to cache, you can fill the cache with statements that your applications will reuse, rather than with statements that are called only a few times, thus getting the best performance increase with the least number of cached statements. You can also avoid caching prepared statements that my be problematic, such as those described in “Usage Restrictions for the Prepared Statement Cache” on page 8-38. Even if the startup class fails, WebLogic Server loads and caches the statements for
future use.
Data Source
Emulate Two-Phase Commit for non-XA Driver
StreamChunk Size
- Required only for large requests/responses
- Appropriate tuning reduces number of socket reads/writes
- Main factors: MTU and request size
- -Dweblogic.ChunkSize and -Dweblogic.utils.io.chunkpoolsize
- Higher memory requirements
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. A server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. See Tune the Chunk Parameters.
1.1.1 Tune the Chunk Parameters
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size:
- weblogic.Chunksize—Sets the size of a chunk (in bytes). The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network's maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
- weblogic.utils.io.chunkpoolsize—Sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
- weblogic.PartitionSize—Sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
Row Prefetch Enabled/Size
Extraction de la documentation de tuning Weblogic
Row Caching with the WebLogic RMI Driver
Row caching is a WebLogic Server JDBC feature that improves the performance of your application. Normally, when a client calls ResultSet.next(), WebLogic Server fetches a single row from the DBMS and transmits it to the client JVM. With row caching enabled, a single call to ResultSet.next() retrieves multiple DBMS rows, and caches them in client memory. By reducing the number of trips across the wire to retrieve data, row caching improves performance.
Note: WebLogic Server will not perform row cachingwhen the client andWebLogic Server are in the same JVM.
You can enable and disable row caching and set the number of rows fetched per ResultSet.next() call with the Data Source attributes Row Prefetch Enabled and Row Prefetch Size, respectively. You set Data Source attributes via the Administration Console. To enable row caching and to set the row prefetch size attribute for a
DataSource or TxDataSource, follow these steps:
1. In the left pane of the Administration Console, navigate to Services→JDBC→Data Sources or Tx Data Sources, then select the DataSource or TxDataSource forwhich you want to enable row caching.
2. In the right pane of the Administration Console, select the Configuration tab if it is not already selected.
3. Select the Row Prefetch Enabled check box.
4. In Row Prefetch Size, type the number of rows you want to cache for each ResultSet.next() call.
DEPASSEMENT DE CAPACITE
Le paramétrage de mise en attente des requêtes sur un pool en saturation se trouve sur la console Weblogic (temps en seconde):
Consoleà${domaine}àServiceàJDBCàData Sourcesà${datasource}àConnection PoolàConnection Reserve Timeout
Lors d’un test de simulation de dépassement de capacité on peut observer la métrique WaitSecondsHighCount atteindre cette valeur (ce qui signifie qu’il y a eu attente et rejet).
Une exception sur la partie cliente intervient sur le rejet avec une Ressource Exception.
Error:Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool XE to allocate to applications,
please increase the size of the pool and retry..
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:559)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:332)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:322)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:431)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:61)
at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1584)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1387)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:438)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:395)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:355)
at weblogic.jdbc.common.internal.RmiDataSource_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Pour prévenir être alerté sur ces échecs, on pourra monitorer l’attribut MBean FailedReserveRequestCount.
Inscription à :
Articles (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
