3. Java Persistence and EJB Performance
3
1. EJB Programming Model
2. The Java Persistence API and Its Reference Implementation
3. Monitoring and Tuning the EJB Container
4. Transaction Isolation Level
5. Best Practices in Enterprise Java Beans
6. Best Practices in Java Persistence
6. Java Persistence and EJB Performance
6
1. EJB Programming Model
2. The Java Persistence API and Its Reference Implementation
3. Monitoring and Tuning the EJB Container
4. Transaction Isolation Level
5. Best Practices in Enterprise Java Beans
6. Best Practices in Java Persistence
7. Java Persistence and EJB Performance
7
JPA Reference Implementation
JPA layer between business logic and
database
13. Java Persistence and EJB Performance
13
JPA Reference Implementation
1 Full Identity Map Objects are never evicted from the cache unless deleted
2 Weak Identity Map Objects are held in Weak References, which allows the
JVM to garbage collect them when there are no other
references from the application Weak Identity Map
3 Soft Identity Map Objects are held in Soft References, which allows the
JVM to garbage collect them when memory is low
4 Soft Cache Weak Identity Map This option maintains a most frequently used subcache
of soft references in addition to the Identity Map cache
5 Hard Cache Weak Identity Map This option maintains a most frequently used subcache
of hard references in addition to the Identity Map cache
14. Java Persistence and EJB Performance
14
1. EJB Programming Model
2. The Java Persistence API and Its Reference Implementation
3. Monitoring and Tuning the EJB Container
4. Transaction Isolation Level
5. Best Practices in Enterprise Java Beans
6. Best Practices in Java Persistence
15. Java Persistence and EJB Performance
15
Monitoring and Tuning the EJB Container
Thread Pool
16. Java Persistence and EJB Performance
16
Monitoring and Tuning the EJB Container
Thread Pool
17. Java Persistence and EJB Performance
17
Monitoring and Tuning the EJB Container
Thread Pool
18. Java Persistence and EJB Performance
18
Monitoring and Tuning the EJB Container
Thread Pool
19. Java Persistence and EJB Performance
19
Monitoring and Tuning the EJB Container
Thread Pool
20. Java Persistence and EJB Performance
20
Monitoring and Tuning the EJB Container
Thread Pool
SNo. PropertyName Description
1 steady-pool-size minimum number of instances maintained in
the pool
2 max-pool-size maximum number of beans in the
pool
3 pool-idle-timeout-in-seconds maximum time that a stateless session bean or
message driven bean is allowed to be idle in
the pool
21. Java Persistence and EJB Performance
21
Monitoring and Tuning the EJB Container
Thread Pool
22. Java Persistence and EJB Performance
22
Monitoring and Tuning the EJB Container
Thread Pool
23. Java Persistence and EJB Performance
23
Monitoring and Tuning the EJB Container
Thread Pool
Stateful Bean Cache Entity Bean Cache
Ready Cache Transactional Cache
Invisible to user
(txnid,entityid)(entityid)
24. Java Persistence and EJB Performance
24
Monitoring and Tuning the EJB Container
Thread Pool
Commit Option C → Bypass Ready cache to improve performance
Only Transactional
Requests
Single Use Entity
25. Java Persistence and EJB Performance
25
Monitoring and Tuning the EJB Container
Thread Pool
Active Session Beans = 20492 - 19087 = 1405
26. Java Persistence and EJB Performance
26
Monitoring and Tuning the EJB Container
Thread Pool
27. Java Persistence and EJB Performance
27
Monitoring and Tuning the EJB Container
Thread Pool
28. Java Persistence and EJB Performance
28
Monitoring and Tuning the EJB Container
Thread Pool
High Cache hit Ratio = Settings are working well
High Miss Ratio/Passivations = Room for improvement
29. Java Persistence and EJB Performance
29
Monitoring and Tuning the EJB Container
Thread Pool
SNo. Observation Improvement
1 Current PoolSize ~ Max PoolSize
Active Session Beans > Max PoolSize
New Max PoolSize = Active Session
Beans
2 Active Session Beans < Max Pool Size Increase idle timeout
30. Java Persistence and EJB Performance
30
Monitoring and Tuning the EJB Container
Thread Pool - EclipseLink Session Cache
31. Java Persistence and EJB Performance
31
Monitoring and Tuning the EJB Container
Thread Pool - EclipseLink Session Cache
32. Java Persistence and EJB Performance
32
Monitoring and Tuning the EJB Container
Thread Pool - EclipseLink Session Cache
33. Java Persistence and EJB Performance
33
Monitoring and Tuning the EJB Container
Transaction Isolation Level
Sno. Transaction Isolation Level Description
1 ReadUncommitted Read data before transaction completion
2 ReadCommitted Only Commited data is read
3 RepeatableRead Multiple reads within txn return same data
4 Serializable All txns occur in isolation
34. Java Persistence and EJB Performance
34
Monitoring and Tuning the EJB Container
Transaction Isolation Level
LockType Strategy Use Case
Pessimistic Lock Lock row of table Highly Concurrent
Optimistic Lock Use version number Data which is seldom
modified
35. Java Persistence and EJB Performance
35
1. EJB Programming Model
2. The Java Persistence API and Its Reference Implementation
3. Monitoring and Tuning the EJB Container
4. Transaction Isolation Level
5. Best Practices in Enterprise Java Beans
6. Best Practices in Java Persistence
36. Java Persistence and EJB Performance
36
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Container Managed Transaction EJB container manages transaction
Bean Managed Transaction Application manages transaction
Transaction Type
37. Java Persistence and EJB Performance
37
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Bean Managed Transaction to narrow the scope of
transaction
Transaction Type
38. Java Persistence and EJB Performance
38
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
SNo. Transaction Attribute Description
1 Required Container executes with client transaction if existent
2 Requires New Container always creates new transaction
3 Mandatory Exception if client not running with transaction
4 Not Supported Client transaction suspended prior to invoking method
5 Supports No transaction created if client transaction non existent
6 Supports New Remote exception if client running with transaction
Transaction Attribute
39. Java Persistence and EJB Performance
39
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Avoid unnecessary transactions by choosing appropriate transaction attributes
Ex: Override Default with Supports attribute
Transaction Attribute
40. Java Persistence and EJB Performance
40
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Control Serialization
Any attribute that does not need to be passivated
should be marked with the transient keyword
41. Java Persistence and EJB Performance
41
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Cache Static Resource References
42. Java Persistence and EJB Performance
42
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Cache Static Resource References
43. Java Persistence and EJB Performance
43
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Local instead of Remote References
Local Pass By Reference : Method
Invocations contained within same
JVM
Remote Pass By Value : Argument copying,
Serialization and Deserialization
Overhead
44. Java Persistence and EJB Performance
44
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Local instead of Remote References
45. Java Persistence and EJB Performance
45
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Local instead of Remote References
46. Java Persistence and EJB Performance
46
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Local instead of Remote References
47. Java Persistence and EJB Performance
47
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Use Local instead of Remote References
48. Java Persistence and EJB Performance
48
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Coarse Grained Access
49. Java Persistence and EJB Performance
49
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Lazy Loading or Prefetching
Lazy loading is a strategy used by many persistence
implementations to load a related entity only when it has been
explicitly accessed
50. Java Persistence and EJB Performance
50
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Lazy Loading or Prefetching
Related Entity Line
is Eager Fetched
by Default
51. Java Persistence and EJB Performance
51
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Lazy Loading or Prefetching
52. Java Persistence and EJB Performance
52
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Lazy Loading or Prefetching
53. Java Persistence and EJB Performance
53
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Database Locking Strategy
Use optimistic locking if data is not likely to be modified
frequently by concurrent transactions.
Use pessimistic locking if data is likely to be modified by
concurrent transactions frequently
54. Java Persistence and EJB Performance
54
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Database Locking Strategy
Optimistic Locking
55. Java Persistence and EJB Performance
55
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Database Locking Strategy
Pessimistic Locking
56. Java Persistence and EJB Performance
56
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
EJB Query Language
57. Java Persistence and EJB Performance
57
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
EJB Query Language
58. Java Persistence and EJB Performance
58
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
EJB Query Language
59. Java Persistence and EJB Performance
59
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Read Only Entity Beans
60. Java Persistence and EJB Performance
60
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
EJB 3.0 Best Practices
Use local interfaces over remote interfaces whenever possible. If only
remote interfaces are available use pass by reference in co located
modules to avoid expensive copying of parameters.
61. Java Persistence and EJB Performance
61
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors
Interceptors are enterprise bean developer defined
methods that intercept a business method invocation.
An interceptor method can be used for a variety of
purposes including but not limited to validation and
preprocessing of data
62. Java Persistence and EJB Performance
62
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors
1. Default invoked for all session bean invocations for all session beans
in a deployment unit
2. Class Level invoked for all method invocations on the session bean they
are bound to
3. Method Level invoked when the method on the session bean is invoked
63. Java Persistence and EJB Performance
63
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors : Default
64. Java Persistence and EJB Performance
64
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors : Class
65. Java Persistence and EJB Performance
65
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors : Method
66. Java Persistence and EJB Performance
66
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors : Exclude Method
67. Java Persistence and EJB Performance
67
Monitoring and Tuning the EJB Container
Best Practices - Enterprise Java Beans
Business Method Interceptors : Best Practice
68. Java Persistence and EJB Performance
68
1. EJB Programming Model
2. The Java Persistence API and Its Reference Implementation
3. Monitoring and Tuning the EJB Container
4. Transaction Isolation Level
5. Best Practices in Enterprise Java Beans
6. Best Practices in Java Persistence
69. Java Persistence and EJB Performance
69
Best Practices in Java Persistence
JPA Query Language Queries
1. Named Queries JPA Query Language Query with Name
2. Named Native Queries Static SQL Query with Name
3. Dynamic Queries JPA Language Queries created at runtime
4. Native Queries SQL Query
70. Java Persistence and EJB Performance
70
Best Practices in Java Persistence
JPA Query Language Queries
Named Query
71. Java Persistence and EJB Performance
71
Best Practices in Java Persistence
JPA Query Language Queries
Named Native Query
72. Java Persistence and EJB Performance
72
Best Practices in Java Persistence
JPA Query Language Queries
Dynamic Query
73. Java Persistence and EJB Performance
73
Best Practices in Java Persistence
JPA Query Language Queries
Native Query
74. Java Persistence and EJB Performance
74
Best Practices in Java Persistence
JPA Query Language Queries
Native Query
75. Java Persistence and EJB Performance
75
Best Practices in Java Persistence
JPA Query Language Queries
Pagination Configuration
76. Java Persistence and EJB Performance
76
Best Practices in Java Persistence
Query Results Cache
77. Java Persistence and EJB Performance
77
Best Practices in Java Persistence
Query Results Cache
78. Java Persistence and EJB Performance
78
Best Practices in Java Persistence
Query Results Cache
Use Named Query
Use Pagination
Use Query Results Cache
79. Java Persistence and EJB Performance
79
Best Practices in Java Persistence
Fetch Type
80. Java Persistence and EJB Performance
80
Best Practices in Java Persistence
Fetch Type
81. Java Persistence and EJB Performance
81
Best Practices in Java Persistence
Fetch Type
82. Java Persistence and EJB Performance
82
Best Practices in Java Persistence
Fetch Type
Select the fetchType based on the relationship. Use
eager fetch for entities loaded together. In cases
where related entities may not be loaded together,
use lazy fetch
83. Java Persistence and EJB Performance
83
Best Practices in Java Persistence
Connection Pool
84. Java Persistence and EJB Performance
84
Best Practices in Java Persistence
Bulk Updates
85. Java Persistence and EJB Performance
85
Best Practices in Java Persistence
Bulk Updates
86. Java Persistence and EJB Performance
86
Best Practices in Java Persistence
Bulk Updates
87. Java Persistence and EJB Performance
87
Best Practices in Java Persistence
Choose Correct Locking Strategy
88. Java Persistence and EJB Performance
88
Best Practices in Java Persistence
Read Without Transactions
89. Java Persistence and EJB Performance
89
Best Practices in Java Persistence
Inheritance
1. SINGLE_TABLE Uses one table for all classes and distinguishes between
instance types by using a discriminator column
2. JOINED Uses one table for the root class, and each subclass is
represented by a table that contains attributes specific to the
subclass
3. TABLE_PER_CASS Uses one table per concrete class; this is an optional
strategy and is not required to be implemented by
persistence providers
EJB stands for Enterprise Java beans. It is one of the several Java APIs for standard manufacture of enterprise software
EJB provide inbuilt support for:-
Life-cycle management
Security
Transaction management
Object pooling
There are several types of enterprise Java beans. The list can be seen below:
Session beans
Entity beans
Message-driven beans
Session beans: these are non-persistent enterprise beans. There are two kinds of session beans:
Stateful: a stateful session Bean maintains client-specific session information across several transactions. It exists for the duration of a single client/server session.
Stateless: A stateless session bean is a type of enterprise bean, which is normally used to perform independent operations. A stateless session bean as per its name does not have any associated client state, but it may preserve its instance state
Entity beans: These beans contain persistent data and it can be saved in the data source. There are two types:
Container managed persistence: these entity beans assign their persistence to the EJB container
Bean managed persistence: these entity beans manage their own persistence.
Message-driven beans: Message-driven beans are enterprise beans that receive and process Java message service messages. They can be accessed only through messaging. They do not have interfaces. Asynchronous communication between the queue and the listener takes place
An EJB 2.1 component has a Home interface, a Business interface, and a bean implementation. This is true for both session and entity beans, whereas message driven
beans have only the bean implementation. A Home interface is used by a client to create
an instance of a bean implementation. The Business interface represents the avail-
able business methods in the bean implementation. When a client creates an instance
of a bean using the Home interface, it is returned an instance of the Business interface
by the EJB container. The client then invokes the business method on this implementation of the Business interface
JPA is a layer of abstraction over the database and represents a mapping of db relational schema to java objects which are available for access by the enterprise java beans layer or the business logic layer. This is depicted in this slide
JPA layer consisyd of 5 main classes namely EntityManagerFactory EntityTransaction EntityManager Query and Persistence that provided a programmatic model to interact with the database entities
The relationship between the different JPA entities is shown in this slide
The relationship between the different JPA entities is shown in this slide
Slide in this figure shows the interaction between the persistence context and the session cache
A cache keeps in memory copies of entities stored in the database to expedite entity access. A persistent context (L1 cache) is an integral part of the JPA specifica-
tion. A persistent context can be transactional or extended. A transactional persistent context’s lifetime spans the life cycle of a transaction, whereas an extended persistent
context’s lifetime may span multiple transaction
This slide depicts L1 and L2 caches in JPA. L1 cache holds entities exclusive to transaction while L2 cache holds shared entities
The size of the L2 cache can affect the performance of an application. While an
L2 cache can significantly improve access to entities because it stores in memory
copies of objects retrieved from the database, it can also lead to a large number of
in-memory objects in a heavily used application. This in turn can force the JVM to do
frequent garbage collections to reclaim unused memory, leading to large pause times
and severely degrading the application performance, negating any performance boost
from using caches. On the other hand an underallocated cache may result in objects
being evicted from the cache more often and leading to more trips to the database,
providing little or no benefit from caching. Thus it is important to understand how
to configure the L2 cache for a JPA implementation
This slide depicts L1 and L2 caches in JPA. L1 cache holds entities exclusive to transaction while L2 cache holds shared entities
The size of the L2 cache can affect the performance of an application. While an
L2 cache can significantly improve access to entities because it stores in memory
copies of objects retrieved from the database, it can also lead to a large number of
in-memory objects in a heavily used application. This in turn can force the JVM to do
frequent garbage collections to reclaim unused memory, leading to large pause times
and severely degrading the application performance, negating any performance boost
from using caches. On the other hand an underallocated cache may result in objects
being evicted from the cache more often and leading to more trips to the database,
providing little or no benefit from caching. Thus it is important to understand how
to configure the L2 cache for a JPA implementation
Next we will discuss monitoring and tuning the ejb container
This slide shows the description of glass fish metrics to monitor to tune the threadpool processing an ejb request
This slide shows the asadmin command to view the threadpool metrics for tuning the ejb container
This slide emphasises the importance of threadpool partitioning for beans
This slide shows how to associate a bean with a threadpool in sun ejb.jar.xml file
This slide shows how to view the ejb container properties using asadmin command
This slide shows describes the tunable bean pool properties
This slide shows describes the glass fish command to view bean pool statistics
This slide shows describes the lifecycle of stateless beans
This slide shows the types of bean caches
This slide shows the use of the commit option C for improving performance of beans with only transactional requests or those wchich are used only once.
This slide shows the example of commands to find the number of active stateful sessionbeans.
This slide shows the example of commands to find the number of cache hits and misses
This slide shows the example of computation of cache hit ratio
This slide shows the example of computation of cache hit ratio
This slide shows the specific steps to improve performance of EJB containers
This slide shows the eclipse link configuration to print cache statistics
This slide shows the cache statistics of number of hits and misses of Customer and Order entities.
This slide shows the option to change the size of cache in eclipse link
This slide describes various transaction isolation levels
This slide describes difference between pessimistic and optimistic lock and their use cases
Next we will discuss monitoring and tuning the ejb container
This slide describes different transaction types in enterprise java beans
This slide describes use of bean managed transaction to narrow the scope of transaction
This slide describes various transaction attributes
This slide describes use of the supports attribute to override default required transaction in ejb
This slide describes use of the transient attribute to control serialization overhead
This slide describes caching of the ejb session
This slide describes 10% improvement in performance if static resources are cached
This slide describes difference between local and remote references
The reference to a local interface is defined in the web.xml as shown in this slide
The EJB module exposes the session bean’s local interfaces with the declaration in the ejb-jar.xml as shown in this slide
The pass-by-reference configuration is done for individual enterprise beans in
the sun-ejb-jar.xml. For example, the ServletDriver invokes the remote method
of OrderSessionBean enterprise bean co-located on the same JVM, and if we still
wanted to pass parameters by-reference instead of by-value, we would use the entry in the sun-ejb-jar.xml as shown in this slide
As shown in this slide there is an 11% difference between the Local and Remote interface scenarios
This slide shows an example of usage of coarse grained access
In the Session Façade design pattern, the server encapsulates multiple smaller tasks into one business operation. The client, instead
of making multiple remote invocations makes one invocation to complete the business operation.
In the code shown placeOrder method of the CheckoutSession Class makes multiple method invocations to place an order
This slide shows an example of usage of coarse grained access
In the Session Façade design pattern, the server encapsulates multiple smaller tasks into one business operation. The client, instead
of making multiple remote invocations makes one invocation to complete the business operation.
In the code shown placeOrder method of the CheckoutSession Class makes multiple method invocations to place an order
This slide shows an example that specifies the fetch group in the sun-cmp-mappings.xml file
This slide shows that the throughput of the eager scenario is 38% of the lazy scenario
This slide shows that the throughput of the eager scenario is 38% of the lazy scenario
This slide shows that the throughput of the eager scenario is 38% of the lazy scenario
1. Create a version column with numeric data type in the primary table
representing the entity bean in the database.
2. Create triggers on the version column so that each time the database row is
updated, the row’s version column is incremented.
3. In the sun-cmp-mappings.xml file specify the following under the
<consistency> element
In the sun-cmp-mappings.xml file specify the following under the
<consistency> element
This slide shows the use of findbyPrimaryKey to fetch order entity
This slide shows the use of EJBQL to fetch orderLine items from db
This slide shows the performance benefit of using EJB QL. In this example, the throughput when using
the findByPrimaryKey scenario is only 22% of using EJB QL
The example in this slide shows configuring a rarely changing entity bean as read-only. The refresh-period-in-seconds parameter is the number of seconds before
the state of the entity instance is reloaded from the database
This slide describes the best practice to use local interfaces over remote interfaces
This slide describes interceptor methods
This slide describes the different level of granularity of interceptor methods.
This slide describes deployment descriptor for default interceptor
This slide describes deployment descriptor for class level interceptor
This slide describes deployment descriptor for method level interceptor
This slide describes deployment descriptor to exclude themethod of a class from default interceptor and class interceptor invocation
This slide describes best practice to use appropriate granularity when using interceptor to prevent performance degradation
Next we will discuss best practices in Java Persistence
Next we will discuss monitoring and tuning the ejb container
Since these queries do not change, most JPA implementations precompile the queries during deployment. These queries support parameter
binding. The example in this slide shows a NamedQuery used to look up an Order entity based on a Customer’s id
The example in this slide shows a Name NativeQuery version of the preceding NamedQuery using a resultClass to map
the returned result set to an Order entity. Disadvantage =Less portable
Dynamic queries are JPA Language Queries created at runtime. The example in this slide shows a query not parameterized and is compiled on each invocation.
Dynamic queries are JPA Language Queries created at runtime. The example in this slide shows a query not parameterized and is compiled on each invocation.
Slide shows the performance of named, named native, dynamic parameterized, and dynamic non parameterized queries. There is a distinct advantage in using named queries or parameterized dynamic queries whenever possible, as the JPA provider can skip the compilation stage during runtime and uses the precompiled queries from its cache
An application can control how much data is retrieved from database and can significantly improve performance in cases where a large col-
lection is retrieved from the database
Most JPA implementations support caching of named query results. If a named query
is executed with the same parameters and the query results cache is enabled, the
persistence provider returns the results from the query results cache, saving a trip
to the database
This Slide shows an example of configuring a query results cache
for the Order entity in the orm.xml file
The orm.xml in the preceding example configures a query results cache for the
query named “findByStatus”, which stores the last 200 result sets of distinct
parameters
Hint specification to expires the cache every 30 minutes and forces the query to execute on the database.
Hint specification to refresh the session cache if the data received from the database by a query is newer than the data in the cache
It is a good performance practice to use named query whenever possible. Use pagination to restrict the number of entities retrieved from the database. Use a query results cache for named queries where applicable
A FetchType of LAZY benefits entities with one-to-many or many-to-many rela-
tionships, where the cardinality of the relationship is high, and the attributes are not
accessed immediately after the entity is loaded.
Figure in slide shows the performance of loading an Order entity with a 1:M relationship with OrderLine entity. The mean
cardinality of the relationship is around 50.
The eager and lazy fetch relationship between the Order entity and the OrderLine entity is marked as shown in this slide
The named query in the preceding example when executed fetches the related OrderLine objects along with the Order object with a specific status. The LEFT keyword specifies that an order should be fetched even if it doesn’t contain any related OrderLine objects
This slide describes when to use lazy or eager fetch types
It is important to set the connection pool to number of request processing threads
This slide shows that with connection pool size of 4, the throughput
is 76% of the throughput with a connection pool size of 12. This is because in the case
of the connection pool of size 4, the request processing threads are waiting to get a
connection from the connection pool
Consider the following example that cancels all orders belonging to a customer. This implementation would result in as many SQL statements as there
are orders in the Collection returned by the query execution.
We can write the same implementation with a JPA QL query that updates the status on the orders with a single SQL query
Figure in slide shows the performance of iterative versus bulk update for a customer that has on average ten orders associated with it. The throughput of an iterative update is 20% of the throughput achievable through a JPA QL bulk update
The example in this slide demonstrates how to configure optimistic locking. Use of optimistic locking improves performance in cases where data is seldom modified
To prevent the overhead of a new transaction on a read only method, use the supports transaction attribute on method.
In the example in this slide, if the client code does not invoke the getOrder()
method in a transaction, the em.find() method looks up the appropriate Order instance without a transaction
There are three strategies in the Java Persistence 1.0 specification for mapping inheritance hierarchy to database tables
The JOINED inheritance strategy is not necessarily a bad choice with respect to performance.In the case of inheri-
tance using the JOINED strategy the cardinality of the relationship is always one,
and looking up single records using the primary key across tables through indexes,
which most databases automatically provide for records using their primary key,
makes no perceptible difference in performance
