Improve JDBC Oracle database transaction performance in Apache-Tomcat

Method 1 – Using Only Datasource

 

The standard way to configure JDBC connections in Tomcat is to define a datasource resource in the “context.xml” file as  follows

<Resource  name="jdbc/DBASE" auth="Container" type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@hostname:port:sid " username="apps"  password="password" maxActive="20" maxIdle="10" maxWait="-1"/>

              

The above resource can then be accessed in the Java code to get a Oracle Connection as follows:

import java.sql.Connection; import javax.sql.DataSource; import javax.naming.InitialContext; import oracle.jdbc.OracleConnection;       /* Only connection related code snippet mentioned below */   // Initialize the variables Connection conn = null; OracleConnection oracleconn = null;   // Invoke the database InitialContext jndiEnc = new InitialContext(); DataSource ds = (DataSource) jndiEnc.lookup("java:comp/env/jdbc/DBASE"); conn = ds.getConnection(); oracleconn = conn.unwrap(OracleConnection.class);

 

This is the way that you will find described in the Tomcat documentation and on most of the websites on internet.

The problem with the above approach is that it does not initialize the database connections when the server is started (or when the web application is deployed). The connection to the database is made only when the above code is executed. Due to this the performance is slow, which may still be okay for most of the cases. But if you need better performance then the next method is recommended.

 

Method 2 – Using Datasource with Factory

 

Using this method, the tomcat on startup creates database connections which are then readily available to be used in the program. This substantially improves the performance compared to the previous method. The resource configuration in “context.xml” is to be done as follows. The main difference compared to the earlier configuration is to add the “factory” parameter.

 

<Resource   name="jdbc/ETTB_DS"   auth="Container"   type="javax.sql.DataSource"   driverClassName="oracle.jdbc.OracleDriver"   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"   url="jdbc:oracle:thin:@hostname:port:sid"   username="apps" password="password"   initialSize="5"   maxTotal="15" />

              

The above resource can then be accessed in the Java code to get a Oracle Connection as follows:

import java.sql.Connection; import javax.sql.DataSource; import javax.sql.PooledConnection; import javax.naming.InitialContext; import oracle.jdbc.OracleConnection;     /* Only connection related code snippet mentioned below */   // Initialize the variables Connection conn = null; OracleConnection oracleconn = null;   /* Invoke the database */ InitialContext jndiEnc = new InitialContext(); DataSource ds = (DataSource) jndiEnc.lookup("java:comp/env/jdbc/DBASE"); conn = ds.getConnection();                          /* The Connection object received is an instance of PooledConnection.    Following line converts PooledConnection to OracleConnection. */ oracleconn = (OracleConnection) (Connection) ((PooledConnection) conn).getConnection();

 

 

Conclusion

Use the Method 2 to improve you application performance  while connecting to Oracle Database on Apache-Tomcat.

 

Business Travel Checklist

This is a checklist for short term business travel to a foreign country.

Onsite Travel Checklist

<![if supportMisalignedColumns]> <![endif]>

Food
Sr. No.	Item	Quantity	Tick Mark
1	Wheat Atta	1 Ziplock bag per 6 Days. One time cooking.
2	Rice	1 Ziplock bag per 10 Days. Two time cooking.
3	Split Dal for Khichdi	1/4 Quantity of rice
4	Toor Dal	1/4 Quantity of rice
5	Chole	1/4 Quantity of rice
6	Black Eye Beans	1/4 Quantity of rice
7	Moong	1/4 Quantity of rice
8	Ghee	Small Bottle for 14 Days
9	Cooking Oil	Small Bottle for 14 Days
10	Spices and Salt	As per the container, half is okay
11	Jaggery	200 grams
12	Corn Flakes & Meusli	1 Packet around 500 grams each for 14 Days.
13	Khakhra	1 Dabba for 10 Days.
13	Sweet (Jaggery Laddoo)	1 Per Day
14	Dry Fruits & Nuts	200 gms each for 14 Days
15	Dates	500 gms for 14 Days
Utensils
Sr. No.	Item	Quantity	Tick Mark
1	Pressure Cooker with Flat Bottom	1 Qty (with Flat Bottom)
2	Pressure Cooker Accessories	1 Qty (extra rubber, valve etc.)
3	Steel Thali	1 Qty (to be used as Plate and Chakla)
4	Rolling Pin (Belan)	1 Qty
5	Office Tiffin Boxes & Bag	1 Qty
Clothing
Sr. No.	Item	Quantity	Tick Mark
1	Office Wear	6 Pairs per week (includes 1 casual pair)
2	Belts	1 Black + 1 Brown + 1 Casual
4	Socks	7 Pairs (including 2 white cotton)
5	Shoes	1 Office + 1 Casual
6	Slipper	1 Pair
7	Winter wear heavy jacket	1 Qty (Choose type depending on time of year)
8	Wind Cheater / Rain jacket	1 Qty
9	Umbrella	1 Qty  (Depending on region and rains)
10	Thermals	2 Pair for winter season. 1 Pair for summer season
11	Woollen Cap	1 Qty (Any time of year)
12	Woollen Socks	1 Qty (Any time of year)
13	Monkey Cap	1 Qty (Winter season only)
14	Muffler	1 Qty (Winter season only)
15	Woollen Hand Gloves	1 Qty (Winter season only)
Cosmetics Etc.
Sr. No.	Item	Quantity	Tick Mark
1	Body Lotion	1 Big Bottle per 3 weeks
2	Face Lotion	1 Olay per 2 month
3	Lip Guard	1 Qty
4	Grooming kit (Scissor, Nail-Cutter)	1 Qty
5	Shaving Kit	1 Qty (1 Blade per 30 Days)
6	Bar of Soap	1 Qty for 30 Days
7	Tooth Paste	1 Medium size for 30 Days
8	Tooth Brush + Tongue Cleaner	1 Qty
9	Cloth Washing Detergent	2 Small sachets per 1 week
10	Cloth Washing Soap	1 Small Bar
Electrical & Electronics
Sr. No.	Item	Quantity	Tick Mark
1	Convertor Plug	1 Qty
2	Kindle	1 Qty
3	SIM  Card of the country	1 Qty
4	Laptop, Charger, Mouse	1 Qty
5	LAN Cable or Wireless modem	1 Qty (as per need)
6	Mobile Charger (and Mobile)	1 Qty
Important
Sr. No.	Item	Quantity	Tick Mark
1	Passport	1 Qty
2	Wallet with Cash and Cards	1 Qty
3	Ticket Printout	1 Qty
4	LOA/Invitation Letter Prinout	1 Qty
5	Hotel Booking Printout	1 Qty

Difference between HTTP PUT and POST

Difference between PUT and POST

The key difference between PUT and POST is that PUT is idempotent while POST is not. No matter how many times you send a PUT request, the results will be same. POST is not an idempotent method. Making a POST multiple times may result in multiple resources getting created on the server.

Another difference is that, with PUT, you must always specify the complete URI of the resource. This implies that the client should be able to construct the URI of a resource even if it does not yet exist on the server. This is possible when it is the client's job to choose a unique name or ID for the resource, just like creating a user on the server requires the client to choose a user ID. If a client is not able to guess the complete URI of the resource, then you have no option but to use POST.

Request	Operation
PUT http://MyService/Persons/	Won't work. PUT requires a complete URI
PUT http://MyService/Persons/1	Insert a new person with PersonID=1 if it does not already exist, or else update the existing resource
POST http://MyService/Persons/	Insert a new person every time this request is made and generate a new PersonID.
POST http://MyService/Persons/1	Update the existing person where PersonID=1

It is clear from the above table that a PUT request will not modify or create more than one resource no matter how many times it is fired (if the URI is same). There is no difference between PUT and POST if the resource already exists, both update the existing resource. The third request (POST http://MyService/Persons/) will create a resource each time it is fired.

HTTP Operations, Safe and Idempotent operations..

Method	Operation performed on server	Quality
GET	Read a resource.	Safe
PUT	Insert a new resource or update if the resource already exists.	Idempotent
POST	Insert a new resource. Also can be used to update an existing resource.	N/A
DELETE	Delete a resource .	Idempotent
OPTIONS	List the allowed operations on a resource.	Safe
HEAD	Return only the response headers and no response body.	Safe

A Safe operation is an operation that does not have any effect on the original value of the resource. For example, the mathematical operation "divide by 1" is a safe operation because no matter how many times you divide a number by 1, the original value will not change. 

An Idempotent operation is an operation that gives the same result no matter how many times you perform it. For example, the mathematical operation "multiply by zero" is idempotent because no matter how many times you multiply a number by zero, the result is always same. 

Similarly, a Safe HTTP method does not make any changes to the resource on the server. An Idempotent HTTP method has same effect no matter how many times it is performed. Classifying methods as Safe and Idempotent makes it easy to predict the results in the unreliable environment of the Web where the client may fire the same request again.

Configuration steps to start the Workflow Notification mailer in Test environments

Introduction

At times, there is a need to receive the notification emails that are sent through the Oracle workflow mailer in Development and Test environments. However, these emails should not go to the mailboxes of the users of the system. Instead, they should be redirected to a common mailbox. This blog article is a step by step guide to configure the workflow mailer for the above objective.

Important Note: These steps should NEVER be performed in the production environment.

Steps

Part 1 - Configure the mail server and email sender

1)      Login using ‘SYSADMIN user and go to responsibility  ‘Workflow Administrator Web Application’ > Workflow Manager

2)     You will see Notification mailer is Down



3) Click on ‘Down’.You will find the below window.


4) To Configure Workflow Mailer, press on Edit button



5) You will find the below window



6) Set the Server Name to your Email /SMTP server. Set the ‘Reply-To-Address’ to ‘NoReplyTo@AtYourCompany.com’.



7) Click on button 'Advanced'



8) Press 'Next'



9) Press 'Next'




10) Press 'Next'



11)   Update from field to ‘Workflow Mailer <Name of the Test Environment>’ for e.g. “Workflow Mailer DEV”




Part 2 - Configure the override address

Override address is the address where all the emails will redirected. This can be configured from front end also. However following are the steps to set it up from back end.

1)      Run the below sql statement

    select fscpv.parameter_value

      from fnd_svc_comp_params_tl fscpt

          ,fnd_svc_comp_param_vals fscpv

     where fscpt.display_name = 'Test Address' 

                     and fscpt.parameter_id = fscpv.parameter_id;

2) The result should be ‘NONE’

3) Now run the below sql update statement and commit

UPDATE fnd_svc_comp_param_vals fscpv 

  SET fscpv.PARAMETER_VALUE = 'redirectaddress@yourcompany.com' --( put the email address to which all emails will be redirected)

WHERE fscpv.parameter_id 

(SELECT fscpt.parameter_id

  FROM fnd_svc_comp_params_tl fscpt

 WHERE fscpt.display_name = 'Test Address');

4) Now run the SQL in Step 1 to verify that the email address has been set as required.

5) Now start the workflow mailer by going to ‘Workflow Administrator Web Application’ > Workflow Manager.   You will see Notification mailer is Down. Click on 'Down'. On next page '1)      Select ‘Start’ from drop down list and Press on Go button.


6) After the above step the workflow notification mailer should start and the status should be 'Running'.

Part 3 - Test the setup

1) Click on 'Workflow Notification Mailer'.



2)  Click on ‘Test Mailer’



3) Select a valid user for which email address has been setup and click 'Accept' button.

Two test emails should be sent to the email address that you have setup in the Part 2 (step 3). The emails should not be sent to the actual email address that is set for the user that you have selected.

This completes the steps needed to redirect emails on your test or development environment. Enjoy!!