If you run it in any other folder you will get an exception Unable to initialize encryption service, verify you are in the domain directory or have specified the correct value for -Dweblogic. RootDirectory If you do not want the database password to be visible in your OS history leave it out when running the command and you will be prompted to provide a password.
After restarting you can test whether the connection pool is present and active using the Weblogic Admin utility by setting up the Weblogic environment as before and then running the command below java weblogic. You can also do a connection test to the datasource by setting up the Weblogic environment as before and then running the command below java weblogic.
Improve this answer. Khetho Mtembo Khetho Mtembo 4 4 silver badges 17 17 bronze badges. Hey, thanks, yes you are right that it is far easier to create a datasource through console. One more question: lets say I create a datasource and correspnding jdbc file is generated.
If I give those files to someone else so that he need not add datasources manually. Will that do? Also you can upvote my quetion if you like. A better approach is to use a WLST script to create and target your datasource to your domain. Manually updating domain's configuration files is not the recommanded way and is a bit risky.
Yes you can indeed give the generated file to someone else. They will need to replace the password-encrypted value with the one that they generate on their Weblogic instance.
They will also need to link their newly copied and updated datasource file to their Weblogic instance as per the above steps. EmmanuelCollin is definately correct doing this by had is a bit risky and using WLST script is another good way of doing it.
Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. Does ES6 make JavaScript frameworks obsolete?
Podcast Do polyglots have an edge when it comes to mastering programming Testing reserved connections can cause a delay in satisfying connection requests, but it makes sure that the connection is viable when the application gets the connection.
You can minimize the impact of testing reserved connections by tuning Seconds to Trust an Idle Pool Connection. If the data source is configured to test connections on reserve, when an application requests a database connection, WebLogic Server tests the connection, discovers that the connection is dead, and tries to replace it with a new connection to satisfy the request. Ordinarily, when the DBMS comes back online, the refresh process succeeds.
However, in some cases and for some modes of failure, testing a dead connection can impose a long delay. To minimize this delay, WebLogic data sources include logic that considers all connections in the data source as dead after a number of consecutive test failures, and closes all connections in the data source. After all connections are closed, when an application requests a connection, the data source creates a connection without first having to test a dead connection.
This behavior minimizes the delay for connection requests following the data source's connection pool flush. WebLogic Server determines the number of test failures before closing all connections based on the Test Frequency setting for the data source:. If your DBMS becomes and remains unavailable, the data source will persistently test and try to replace dead connections while trying to satisfy connection requests.
This behavior is beneficial because it enables the data source to react immediately when the database becomes available. However, testing a dead database connection can take as long as the network timeout, and can cause a long delay for clients.
To minimize this delay, the WebLogic data sources include logic that disables the data source after 2 consecutive failures to replace a dead connection. When an application requests a connection from a disabled data source, WebLogic Server throws a PoolDisabledSQLException immediately to notify the client that a connection is not available. For data sources that are disabled in this manner, WebLogic Server periodically runs a refresh process.
The refresh process does the following:. You can also manually enable the data source using the Administration Console. Database connection testing during heavy traffic can reduce application performance. To minimize the impact of connection testing, you can set the Seconds To Trust An Idle Pool Connection attribute in the JDBC data source configuration to trust recently-used or recently-tested database connections and skip the connection test.
If Test Reserved Connections is enabled on your data source, when an application requests a database connection, WebLogic Server tests the database connection before giving it to the application. If the request is made within the time specified for Seconds to Trust an Idle Pool Connection since the connection was tested or successfully used and returned to the data source, WebLogic Server skips the connection test before delivering it to an application.
If Test Frequency is greater than 0 for your data source periodic testing is enabled , WebLogic Server also skips the connection test if the connection was successfully used and returned to the data source within the time specified for Seconds to Trust an Idle Pool Connection. Seconds to Trust an Idle Pool Connection is a tuning feature that can improve application performance by minimizing the delay caused by database connection testing, especially during heavy traffic.
However, it can reduce the effectiveness of connection testing, especially if the value is set too high. The appropriate value depends on your environment and the likelihood that a connection will become defunct.
You should set connection testing attributes so that they best fit your environment. For example, if your application cannot tolerate database connection failures, you should set Seconds to Trust an Idle Pool Connection to 0 and make sure Test Reserved Connections is enabled so that WebLogic Server will test every connection before giving it to an application.
If your application is more sensitive delays in getting a connection from the data source and can tolerate an occasional connection failure, you should set Seconds to Trust an Idle Pool Connection to a higher number, set Test Frequency to a low number, and enable Test Reserved Connections.
With these settings, your application would rely more on testing connections in the pool when they are not in use rather than when an application requests a connection. The Test Table Name attribute is used in connection testing which is optionally performed periodically or when you create or reserve a connection, depending on how you configure the testing options.
For database tests to succeed, the database user used to create database connections in the data source must have access to the database table. If not, you should either grant access to the user make this change in the DBMS or change the Test Table Name attribute to the name of a table to which the user does have access make this change in the WebLogic Server Administration Console.
If set and if the database is unavailable when the data source is created, WebLogic Server attempts to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds.
This option applies to connections created when the data source is created at server startup or when the data source is deployed or if the initial capacity is increased. It does not apply to connections created for pool expansion or to replace a defunct connection in the pool. By default, Connection Creation Retry Frequency is 0 seconds. When the value is set to 0, connection creation retries is disabled and data source creation fails if the database is unavailable.
You use these two attributes together to enable connection requests to wait for a connection without disabling your system by blocking too many threads. Also see " Enable connection requests to wait for a connection " in the Administration Console Online Help. When an application requests a connection from a data source, if all connections in the data source are in use and if the data source has expanded to its maximum capacity, the application will get a Connection Unavailable SQL Exception.
To avoid this, you can configure the Connection Reserve Timeout value in seconds so that connection requests will wait for a connection to become available.
After the Connection Reserve Timeout has expired, if no connection becomes available, the request will fail and the application will get a PoolLimitSQLException exception. If you set Connection Reserve Timeout to -1 , a connection request will timeout immediately if there is no connection available.
If you set Connection Reserve Timeout to 0 , a connection request will wait indefinitely. The default value is 10 seconds. See " Enable connection requests to wait for a connection " in the Administration Console Online Help. Connection requests that wait for a connection block a thread. If too many connection requests concurrently wait for a connection and block threads, your system performance can degrade. To avoid this, you can set the Maximum Waiting for Connection HighestNumWaiters attribute, which limits the number connection requests that can concurrently wait for a connection.
If you set Maximum Waiting for Connection to 0 , connection requests cannot wait for a connection. If the maximum number of requests has been met, a SQLException is thrown when an application requests a connection. A leaked connection is a connection that was not properly returned to the connection pool in the data source. When you set a value for Inactive Connection Timeout, WebLogic Server will forcibly return a connection to the data source when there is no activity on a reserved connection for the number of seconds that you specify.
When set to 0 the default value , this feature is turned off. Note that the actual timeout could exceed the configured value for Inactive Connection Timeout. The internal data source maintenance thread runs every 5 seconds.
When it reaches the Inactive Connection Timeout for example 30 seconds , it checks for inactive connections. To avoid timing out a connection that was reserved just before the current check or just after the previous check, the server gives an inactive connection a "second chance. When your applications attempt to get a connection from a data source in which there are no available connections, the data source throws an exception stating that a connection is not available in the data source.
To avoid this error, make sure your data source can expand to the size required to accommodate your peak load of connection requests. With the Statement Timeout option on a JDBC data source, you can limit the amount of time that a statement takes to execute on a database connection reserved from the data source. If your JDBC driver does not support this method, it may throw an exception and the timeout value is ignored. When Statement Timeout is set to -1, the default statements do not timeout.
To minimize the time it takes for an application to reserve a database connection from a data source and to eliminate contention between threads for a database connection, you can add the Pinned-To-Thread property in the connection Properties list for the data source, and set its value to true. When Pinned-To-Thread is enabled, WebLogic Server pins a database connection from the data source to an execution thread the first time an application uses the thread to reserve a connection.
When the application finishes using the connection and calls connection. When an application subsequently requests a connection using the same execute thread, WebLogic Server provides the connection already reserved by the thread. There is no locking contention on the data source that occurs when multiple threads attempt to reserve a connection at the same time and there is no contention for threads that attempt to reserve the same connection from a limited number of database connections.
These features rely on the ability to return a connection to the connection pool and reacquire it if there is a connection failure or connection identity does not match. Because the nature of connection pooling behavior is changed when PinnedToThread is enabled, some connection pool attributes or features behave differently or are disabled to suit the behavior change:.
When PinnedToThread is enabled, the maximum capacity of the connection pool maximum number of database connections created in the connection pool becomes the number of execute threads used to request a connection multiplied by the number of concurrent connections each thread reserves.
This may exceed the Maximum Capacity specified for the connection pool. You may need to consider this larger number of connections in your system design and ensure that your database allows for additional associated resources, such as open cursors.
Also note that connections are never returned to the connection pool, which means that the connection pool can never shrink to reduce the number of connections and associated resources in use. You can minimize this cost by setting an additional driver parameter onePinnedConnectionOnly. Any additional connections required by the thread are taken from and returned to the connection pool as needed.
Set onePinnedConnectionOnly using the Properties attribute, for example:. If your system can handle the additional resource requirements, BEA recommends that you use the PinnedToThread option to increase performance. If your system cannot handle the additional resource requirements or if you see database resource errors after enabling PinnedToThread , BEA recommends not using PinnedToThread.
To deploy a data source to a cluster or server, you select the server or cluster as a deployment target. When a data source is deployed on a server, WebLogic Server creates an instance of the data source on the server, including the pool of database connections in the data source. When you deploy a data source to a cluster, WebLogic Server creates an instance of the data source on each server in the cluster.
On server startup, WebLogic Server attempts to create database connections in the data sources deployed on the server.
When you set a value for this attribute, the value is passed into java. Select Show advance options. Click the Testing tab. Click Test pool. Click the name of the server whose JNDI tree you want to view.
Select the name of the data source that you want to restart and select the Targets tab. Select Data Sources in the center of the page. Connection pooling means that connections are reused rather than created each time a connection is requested. To facilitate connection reuse, a memory cache of database connections , called a connection pool , is maintained by a connection pooling module as a layer on top of any standard JDBC driver product. Change the Maximum Capacity to the count required for your environment.
Category: technology and computing databases. What is generic DataSource in WebLogic? What is multi DataSource in WebLogic? What is connection pool in WebLogic? What is data source in SOA? How do I stop WebLogic datasource? Starting and Stopping a Data Source.
In the left-hand pane of the console, expand Services and select Data Sources. How do I test datasource in WebLogic 12c?
0コメント