JPA: good and bad? FAQs

Q: How does the EJB expert team get rid of the transaction descriptor?

A: In the Session Bean and message-driven bean, the transaction behavior can be controlled through descriptors and annotations. In addition, we change the default transaction attribute to "required", which is more common than the previous value "supports. Therefore, you do not need to configure transaction behavior for the business method.

JPA entities are only available locally, with a focus on the domain model. Therefore, you cannot configure transactions (or remote boundaries or security) on the JPA entity ). Instead, you must use Session Bean fa C Ade (or message-driven bean) to use these entities through the EJB protocol. Generally speaking, this is a good thing. The granularity of configuration security, remote processing, and transactions should be much coarse than that of persistent data. JPA focuses on persistent data and integration with other EJB components and Java EE specifications to take care of other enterprise concerns.

Q: Do I recommend "long" or "long" for the primary key "? What if null is allowed?

A: it actually depends on your data model. If your data model allows the primary key to be null, use long. If your data model requires that the primary key column cannot be null, use long. In general, I think that for a non-composite primary key, it is easy to confuse null as a valid value, so I tend to use long instead of long.

Problem: You said that EJB 2.0 does not support inheritance, but it can be used in several different locations (remote/bean), but not locally. Please explain.

Answer: According to the appendix D3 of the EJB 2.1 specification:

The current EJB specification does not specify the concept of component inheritance.

On the other hand, the JPA specification does define the concept of Object Inheritance. We have handled the various issues and complexities pointed out in the EJB 2.1 specification and now allow full multi-state queries and associations.

Q: When will bea support/release ejb3?

WebLogic Server 10 technology preview is a Fully Compliant Java ee 5 Application Server. It includes the complete ejb3 support. WebLogic Server 10 was released around late March.

In addition, Kodo is a fully compliant production-ready JPA implementation and has been released.

Q: Does JPA support combination of primary keys?

A: JPA supports natural ID and combination ID, as well as database assignment or realization of assigned numeric values.

Q: Is there a spring template that can be used outside the container like a JDBC template?

A: Yes. Spring 2 has a JPA template. However, spring 2 can execute JPA exception translation on any bean marked with @ repository. Therefore, in general, it is better for new applications to directly use the jpa api instead of another template layer. The template method is reasonable for using templates and existing applications migrating to JPA.

In addition, you can deploy the persistence unit of JPA to spring like in the Java EE server. Spring injects and searches the entitymanager specified in the JPA specification to comply with container rules.

Q: Does JPA support jdk1.4?

A: JPA requires Java 5 or an updated version.

Q: Does a range query return the total number of results (for example, 1-10 of the 538 results )?

A: No. To obtain the total number, you must issue another query. In the general mode, the total number is obtained when the first search is executed, and then the total number is stored in a convenient location (session Status, Cookie, etc.) through the page browsing result ):

　　if (isFirstPage()) { // this is the first time we're executing this query 
　　Query q = em.createQuery("SELECT COUNT(p) FROM Product p WHERE ..."); 
　　long count = ((Long) q.getSingleResult()).longValue(); 
　　// store count somewhere stateful 
　　} 
　　Query q = em.createQuery("SELECT p FROM Product p WHERE ..."); 
　　q.setFirstResult(page * PAGE_SIZE); // page is stored somewhere stateful 
　　q.setMaxResults(PAGE_SIZE); 

Q: Is hibernate with JPA wrapper an ejb3 implementation?

A: The JPA specification is a complete subset of the ejb3 specification. Therefore, the JPA implementation itself is not a complete ejb3 implementation. I don't know how ejb3 is implemented in RedHat. However, Hibernate is a JPA implementation.

Q: Is JPA better than hibernate?

A: JPA is a specification, while Hibernate is an implementation. Therefore, this is a comparison of different things. It is certain that using standard APIs has more advantages than using proprietary APIs, but there is no real disadvantage.

Q: Do I no longer need to learn and use hibernate?

A: One of the goals of the standardization team regarding JPA 1 is to develop an API that can be implemented by many vendors, and developers can code this API, rather than using APIs specific to private providers. We have successfully achieved this goal, so you only need to use the vendor-specific API to obtain the features that the JPA specification does not solve but are required in your application. My advice is to use JPA APIs as much as possible. However, when you need a feature that is open to the vendor but not provided in the Specification, use the API that is unique to the vendor.

For example, openjpa provides the save point function, but the JPA specification does not. Therefore, openjpa developers who want to use the save point should use JPA specifications for most of the Code content, and use openjpaentitymanager to set and manage the save point.

Q: Has the specification solved the cache problem?

A: The JPA specification does not solve the level-2 Cache problem (entitymanagerfactory-level). However, it provides some data lock and consistency rules that must be followed to implement this cache, even when cache is enabled.

A small number of cache-related topics may be solved in future JPA standard versions, but most cache topics do not have to specify rules, so that different vendors can easily complete different tasks. The most important content added here is some basic Cache Control APIs, such as revoking some object IDs or fixing some frequently accessed IDs to the cache.

Q: Since the Entity Manager undertakes all the heavy workloads, what is the value of Session Bean?

A: entitymanager is responsible for the interaction between the domain object model and the database, but still implements Security, transaction control, remote processing, and stateful temporary data storage in the session, the operating unit programming model cannot solve the above problems. The session bean is also the deployment unit and public service boundary. Therefore, Session Bean is the place where all business code is defined. In other words, the session bean is the focus of the EJB container, and the JPA implementation is used in the Session Bean.

Of course, you can also directly use JPA from servlet or JSP or any other place where Java 5 can be used. In this case, you must manage your own transactions, handle cluster service failover, and manage your service redeployment.

Q: How many concurrent transactions can ejb3 process compared with ejb2?

A: From the Perspective of pure Session Bean, at least in Weblogic server, there is no difference in the number of concurrent transactions. That is, if your application is converted from ejb2 Session Bean to ejb3 Session Bean, but the persistence mechanism is not modified at all, no major difference may be found. This is because the ejb3 specification focuses on improving the programming model for most changes to the Session Bean section.

From the perspective of the Entity Bean, I think that for most applications, WebLogic Server's EJB 2.1 and JPA support the same number of concurrent transactions. You may find that JPA has higher scalability for non-primary key queries. Once you begin to study functions such as Kodo locking groups, you can obtain more concurrent transactions from the JPA-based system for a fixed domain model.

Q: How to Apply jpa for the AquaLogic DSP?

Answer: The AquaLogic DSP focuses on multiple storage access to data and provides data as a data service, which is usually presented as XML or SDO. The JPA specification focuses on Java APIs that interact with data storage. It can be imagined that JPA is bound to the AquaLogic DSP, or SDO is bound to the Kodo product (JPA Implementation of BEA ).

Q: Does JPA support inert loading?

Answer: Yes. By default, fields of the collection and map types are retrieved by inertia, while all other fields are actively obtained. By specifying the "Fetch" attribute in the persistent annotation of a field, you can control the behavior statically based on each field.

Q: What is the best place to implement the process, for example, checking many users and their accounts (in banking applications) to pay interest? Is it implemented in the database storage process, using JPA in EJB, or both?

A: based on my experience, this actually depends on organizational factors, not other factors. Some studios prefer to perform a lot of encoding in the stored procedure, while others prefer to implement their business logic in Java. Each method has its own advantages and costs.

Despite this, there are still some problems that may lead them to give priority to one of the environments. In your example, executing a large amount of computing in the database may be faster than loading data into the memory, so it may be reasonable to use the stored procedure. On the other hand, the database will have a negative impact on the users of the application, so it is best to pay a certain price to pull the data across the network, so that the database can be used as a strict storage system, instead of computing engines. Alternatively, if the rest of the application mainly uses JPA, you may want to use the jpql bulk update feature for updates.

Q: Can I perform bulk update without first loading data into the memory?

A: Yes. You can use jpql to Perform Batch update and delete:

Update employee e set E. Salary = E. Salary * 1.1 where E. Salary <100000

Q: What are your plans for kodo JDO? Does JPA replace all JDO functions? If so, is there any timetable? If not, will you continue to actively develop JDO?

A: Bea is still completely loyal to JDO. From the normative point of view, I think that after a while, JPA will contain more and more features in the current JDO specification. However, I don't know how sun planned the integration between JDO and JPA.

Q: What is a persistence unit?

A: The persistence unit is a set of classes and configuration settings. You can create entitymanagerfactory Based on the set. It appears as an entry in the persistence. xml file.

Question: How to test JPA in WebLogic 9.2

A: You can use openjpa or Kodo in WebLogic 9.2. This server does not execute Session Bean persistence unit injection, but this can be done on Server 10.0, and in Server 9.2, there is no Kodo console integration. However, apart from the bootstrap injection issue, you should be able to successfully use JPA in WebLogic 9.2, including participating in managed transactions.

Q: What concepts does a JDBC connection correspond to in JPA?

A: JPA entitymanager is basically equivalent to a JDBC connection, while JPA entitymanagerfactory is conceptually similar to a JDBC data source. JPA entitytransaction (available only outside the JTA/appserver context) is equivalent to the transaction control API for JDBC connection.

In openjpa, entitymanager may use multiple different JDBC connections in its lifecycle. See openjpa. connectionretainmode for details.

Problem: For the fetch type, if it is automatically loaded by default, the provider may ignore the lazy loading command. Therefore, even if the field is set to inert, unnecessary data may be loaded. Will the future specification be changed to be consistent with the fecth type? What problems will this involve?

A: Usually, openjpa never ignores the fetchmode configured by the user. This is a prompt rather than a rule, because the inert loading is actually a concern in the optimization process and should never have an influence on the behavior of the application *. The JPA specification tries to avoid any explicit performance tuning policies, because different network topologies, data storage systems, and application behavior require different tuning considerations.

For example, openjpa allows dynamic control of fetch configuration during runtime. This means that it may statically configure the object model, so that some fields can be asynchronously loaded, and then dynamically add one of the fields to the current fetch plan. This will cause openjpa to violate the static definition of the inertia settings.

At the end of the day, if an incorrect data loading operation is performed, you should be able to easily evaluate other implementations and transfer threats to another implementation to minimize the required functionality. This is one of the major advantages for a large number of vendors to adopt JPA specifications.

* Of course, if you rely on the inertia loading settings to prevent loading certain data, so as not to be transmitted to different layers (that is, for data security), there is an important Behavioral Impact on the inertia loading. In openjpa, you can use the fetch group to control which data is precisely detached when a Data graph is sent over a cable.

Q: Is it difficult to change the fetch mode during running?

A: The JPA specification does not provide any tools for this purpose. Openjpa provides detailed control over fetch features through the fetch planning interface. The join fetch structure of jpql can also be used to limit the active fetch prompts.

Q: When Optimistic Locking is used, does @ version annotation only support int fields? Can it be datetime?

A: According to JPA requirements, @ version can be used for int, long, short, integer, short, long, and timestamp fields. (Section 9.1.17 of the JPA Specification ).

Q: Can I call a stored procedure in JPA?

A: The JPA specification only supports select SQL statements (called through entitymanager. createnativequery (), or @ namednativequery annotation or named-native-query XML element ). However, I think most implementations support calling stored procedures in the same way.

Q: In ejb3, updating a single field/column of the Entity Bean will result in updating all fields/columns in the DB row or updating only the columns changed in the DB row?

A: This action depends on the implementation. Openjpa updates only the columns corresponding to the modified field. However, we may add the update-all-columns option in some locations. Please refer to OPENJPA-38.

Q: How does ejb3.0 Replace the ejbload () and ejbstore () callback methods in ejb2.0?

A: The JPA specification provides some callback methods that can be implemented randomly (individually.

Q: How does ejb3.0 replace ejb2.0 CMP and BMP?

A: The ejb3 JPA specification provides a complete functional replacement for ejb2 CMP. The JPA specification does not solve the persistence of bean management. If you want to achieve your own persistence, you should continue to use BMP, or you 'd better use Session Bean fa C Ade for custom persistence.

Q: Can the name query be outside the JPA object? As in the session bean or help class?

A: The JPA implementation only scans entity classes (ing superclass and embedding classes) to find named queries. I hope that the future JPA standard version will provide a way to restrict the name query to a Class Object. At that time, I can think that the name query can be defined anywhere.

You can define a name query in the orm. xml file and point your persistence unit to the Orm. xml file. The JPA specification allows you to merge any number of ORM. XML files.

Q: Does jpql support multi-database queries?

A: The JPA specification does not require that you only use a single database (or even a relational database ). Therefore, you can access multiple databases at will. However, as far as I know, this is not the case with the current JPA implementation, unless multi-database queries are implemented through the work of the database side.

Q: Can the select clause in jpql pull data from multiple entities?

Answer: Yes. The jpql language allows query aggregation and projection. Therefore, the following statements are valid jpql statements:

Select P. Name, P. contactinfo. phonenumber from person P
Select P. Address. State, AVG (P. Salary) from person P group by P. Address. State

Q: Does the JPA specification solve the cache problem?

A: The JPA specification only addresses the actions of the transaction working set of the given entitymanager-related objects. It is called "persistent context ". In some respects, this is a cache, but it is usually used to maintain transaction consistency, not for performance reasons.

The JPA specification does not address performance caching, such as openjpa data caching and query caching. However, the rules in the Specification imply certain behavior constraints for such performance caches.

All in all, the JPA specification focuses only on API behavior, and most performance-related optimizations are completed by various implementations. However, all reliable implementations should have some data cache as an option.

Q: WebLogic Server 9.0 still only supports ejb2.0, right?

Answer: Correct. WebLogic Server 10.0 is the first Bea product that fully supports ejb3 specifications. In WebLogic Server 9, you can use JPA through the BEA Kodo product.

Q: What is the recommended JPA tutorial?

A: Many JPA tutorials are provided in the Kodo document.

Q: Is there any way to configure the table prefix across all entity tables?

A: This method is not provided in the JPA specification. In openjpa, you can create an extended dbdictionary and override the getvalidtablename () method to implement this function.

Q: Is it possible to modify the ORM binding through programming (for example, rewrite some of the ORM configurations specified in Orm. XML )?

A: It is not implemented through the JPA specification. Openjpa provides some methods for creating ing information programmatically. This specification does provide a method for creating entitymanager, transfer supplier-specific override content to persistence. XML data.

Problem: we are building a large application, with 350 objects adhering to the JPA specification. When we use Kodo 4.1 to persist these objects, its SELECT query eventually connects most of the tables in each query, which makes Kodo quite slow. Toplink essentials only connects a small number of related tables. What are your suggestions for solving this problem?

A: I think this is related to the different default behaviors of "one-to-one" and "many-to-one" fields. I guess it will be clear if you tell Kodo to perform inert loading on the "one-to-one" and "Multiple-to-one" field types. If this does not work, or if you want more help to analyze your specific use cases, please email your plinskey@bea.com.

Q: Can developers use JPA to control the table connection mode?

A: it cannot be directly controlled and is not implemented through specifications. However, most implementations may provide some ways to influence how to connect. For more information about openjpa, see the documentation on proactive fetching.

Q: Where to specify the data source?

A: The data source is usually in persistence. according to your implementation and the default behavior of the application server, the value specified in XML may need to be set for JTA-data-source and/or non-JTA-data-source.

Q: Is the JPA specification planned to support bi-temporal in the future )?

A: As far as I know, the JPA standardization team has no plans to provide any temporal functions.

Q: If an Optimistic Locking exception is thrown, do you know which columns conflict?

A: No. You can know which instances fail, but are not fields. Given failed instances, it is easy to load new values from the database and compare them.