Java Persistence API: Persistence unit (persistence Units)
If you intend to use JPA in your application, you will need to use the persistence unit (persistence Units). A persistence unit has a unique name and is responsible for defining how a set of entities in an app is managed and persisted. Using the persistence. xml file in your app to set up persistence units, you can configure multiple persistence units, but each cell has a unique name.
The persistence unit contains properties such as:
Entity classes within the scope of the persistence Unit (scope)
Provide persistent persistence provider (persistence Provider) or library for the above entity classes
Data source for the above entity class
Transaction type used by the app (Transaction type)
The persistence unit can be packaged into a war file, a Ejb-jar file, a part of the ear file, or a jar file that can be directly used by the application.
The scope of the persistence unit (scope) depends onPersistenceThe location of the. xml file. In general, the IDE can use the boot interface to correctly placePersistenceThe location of the. Xml. For example, using the persistence unit created by the IDE for the EJB module,PersistenceThe. xml file will be placed in the src/conf directory of the EJB module, and when you package the module,PersistenceThe. xml file is placed in the Meta-inf directory of the EJB jar file. The scope of this persistence unit is the class in the EJB jar file.
Note: The location of thepersistence. xml file determines the root of persistence (persistence root). The root of the persistence is the jar file or the directory containing the Meta-inf directory (provided that persistence. XML is located here).
Persistence Provider (PersistenceProvider)
The persistence provider refers to the implementation of JPA. A persistence provider is a library that provides persistent objects to your app. For example, NetBeans binds TopLink Essentials as a persistence provider, while TopLink Essentials is also the Sun Java System application Server Platform Edition 9 (Gla Ssfish) reference implementation and default configuration. TopLink Essentials includes two jar files of Toplink-essentials.jar and Toplink-essentials-agent.jar. You can use other persistence providers such as Hibernate.
Data source
A data source refers to a database that provides entity storage.the data source must be registered on the server and specified with the Jndi name。 If the transaction is a JTA transaction managed by the container
Then the data source must be a JTA data source. If the transaction is managed by the application, the data source is specified according to the JDBC database connection registered in the IDE.
In a Java SE environment, a database can be specified by a data source, or other methods can be used, depending on the requirements of the persistence provider.
Transaction type
The persistence unit specifies how transactions are managed. The transaction type depends on the target container, and if the target container is a Java EE container, you can use container management or application management. If that's not the case, you can only use app management.
The container uses the Java Transaction API to manage transactions. You must deploy your app in a Java EE container, and your data source must support JTA.
In persistence. XML, the transaction type is set to JTA. If you use GlassFish this is the default option.
The application is responsible for transaction processing. In the persistence. xml file, it is set to Resouce_local
<?xml version= "1.0" encoding= "UTF-8"?>
<persistence version= "1.0"
Xmlns:persistence= "Http://java.sun.com/xml/ns/persistence"
Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"
xsi:schemalocation= "Http://java.sun.com/xml/ns/persistence persistence_1_0.xsd" >
<!-- The name attribute is used to define the names of the persisted units (name required, and null values are also valid);
Transaction-type specifying the transaction type (optional) -
<persistence-unit name= "Unitname" transaction-type= "JTA" >
<!--description information. (optional)--
<description> </description>
<!--an implementation class for the Javax.persistence.PersistenceProvider interface (optional)--
<provider> </provider> <!--Specify a persistence provider --
<!--Jta-data-source and Non-jta-data-source are used to specify the global Jndi name of the Jta and/or NON-JTA data source used by the persistence provider (optional)--
<jta-data-source>java:/MySqlDS</jta-data-source>
<non-jta-data-source> </non-jta-data-source>
<!--Declare the location of the orm.xml. That is, specify the mapping file (optional)--
<mapping-file>product.xml</mapping-file>
<!--add additional jar files as a relative path based on the jar file containing the persistence.xml. Specify additional jars for managed classes (optional) --
<jar-file>, .... /lib/model.jar</jar-file>
<!--explicitly list entity classes, which should be explicitly listed in the Java SE environment. (optional)--
<class>com.domain.User</class>
<class>com.domain.Product</class>
<!--declares whether the @enity class is added to the context when the scan jar file is labeled. If you do not scan, the following: (optional)--
<exclude-unlisted-classes/>
<!--vendor-specific properties (optional)--
<properties>
<!--Auto Output schema Create DDL statement value can be create-drop/create/update
It is worth noting that create-drop he will delete all table-open re-creation after the session is closed. -
<property name= "Hibernate.hbm2ddl.auto" value= "Update"/>
<property name= "Hibernate.show_sql" value= "true"/>
</properties>
</persistence-unit>
</persistence>
Usually in enterprise development, there are two ways of doing this:
1. First build the table, then write the configuration file and entity bean according to the table. Developers who use this scenario are affected by traditional database modeling.
2. Write the configuration file and the entity bean before generating the table, and the developers using this scheme are using the idea of domain modeling, which is more oop than the previous idea
It is recommended to use the second (Domain modeling idea), which, from software development, is more object-oriented than the first thought. The idea of domain modeling is also a new model thought, the first is the traditional modeling thought, has 10 years of development history, and the field modeling thought is only in recent years, this kind of thought is more object-oriented
This article is from the "Qin Feng" blog, make sure to keep this source http://leoxia.blog.51cto.com/10825018/1718055
JPA Persistence persistence.xml configuration file is a detailed argument