EJB 3 Performance Homework Help, Assignment Help, Online Tutor, Tutoring

Submit Assignment

* *

Payment Online Assignment Help

Asp dot net Project Homework

Homework Help

sfsf

EJB 3 Performance

Improving Performance

There are a number of issues that can cause bad performance at the persistence tier

• poor design due to lack of understanding the technology

• weak vendor support

• not working with the database team during the design phase

The persistence provider will generate the SQL statements, so you must be able to know how to obtain these so that you can confirm what is being sent to the database.

You may be able to improve performance by merging two small tables, for example say you had a tabled called "billing_details" and another called "address", we will always require an address thus there is JOIN performed between the two tables. You could merge the two tables (normalize) thus the JOIN would no longer be required.

We could go the other way and break down a table, especially if most of the data in the table is not required, for an example you may have a seller table which contains columns like purchase date, manufacturing date, warranty information, picture, etc. Most of this information is not frequently used, so we generally mark these as lazy load, however some vendors have different defaults for example some vendors BLOBs fields are not lazy loaded by default. You split this table into two items and item details and share the same primary key you could then set the fetch mode to lazy load.

Choosing the right inheritance strategy can also improve performance, there are three types of inheritance mapping (see persisting entities for more information), the single-table strategy will probably give you the best performance advantage, the reason for this is that all entities are stored in a single table and JOINs between tables are avoided.

Improving Query Performance

It may be worth enabling a higher level of logging in the persistence provider, thus you can obtain the full SQL statements used, this then can be "tuning utilities" to try and get the most optimized SQL.

Like all databases unless tables are small try to avoid full table scans, try and use a WHERE clause if possible, also make sure that the DBA has created indexes on large column tables that you do not need to retrieve specific columns.

Try to use indexes for relationship fields, otherwise full table scans will happen, again liaise with the DBA to obtain the best table structure.

The last performance improvement can be to limit the number of rows retrieved (this is vendor specific), you can pass the JDBC fetch size as a vendor-specific @QueryHint in either named or dynamic queries