Terry's Blog

Enable JPA 2.0 on Weblogic Server Support for JPA 2.0 in WebLogic Server is provided as a patch, because JPA 2.0 is part of Java Platform, Enterprise Edition (Java EE) 6. Therefore, enabling JPA 2.0 support in the current release results in WebLogic Server not meeting all Java EE 5 compatibility requirements. To maintain Java EE 5 compatibility in the current release, the files required for the support are not enabled by default, although they are included in a standard WebLogic Server installation. Install the Patch - Using Smart Update To install the patch using Smart Update, do the following: Ensure that you are logged in to My Oracle Support. For information, see  http:\\support.oracle.com . Start Smart Update, as described in " Starting Smart Update ." In the  Target Installation  panel of the main Smart Update window, select the target installation. Select the  Get Patches  tab. In the available patches panel, select the check box for...

Reference: http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_%28ELUG%29

Using Sequence Objects When using a database that supports sequence objects (such as Oracle Database), EclipseLink can use a database sequence object to automatically generate identifiers for your persistent objects. Using A Default Sequence EclipseLink can produce a default sequence during schema generation. If you use schema generation, then specify that your identifier should be generated and that the SEQUENCE strategy be used to perform the generation. In the following example, the @GeneratedValue annotation indicates that the identifier value should be automatically generated; a strategy of SEQUENCE indicates that a database sequence should be used to generate the identifier. EclipseLink will create a default sequence object during schema generation that will be used at run time. @ Entity public class Inventory implements Serializable {   @Id @GeneratedValue ( strategy=GenerationType. SEQUENCE ) private long id; ...

In entity bean, the foreign key usually replaced by the referential relationship such as : public class Status implements Serializable {     /**      *      */     private static final long serialVersionUID = 1L;     @Column(name="creation_datetime", nullable = false)     private Timestamp creationDatetime;     @Id     @Column(name="seq_no", nullable = false)     @GeneratedValue(strategy=GenerationType.IDENTITY)     private Integer seqNo;     @Column(name="status", nullable = false)     private String status;     @Column(name="car_id", nullable = false, insertable=false, updatable=false)     private String carId;     @ManyToOne     @JoinColumn(name = "car_id")     private Transaction transaction;     pub...

For EntityManager: It depends on how you obtained it.  If you created it using EntityManagerFactory you will have to close it no matter what framework you use. If you obtained it using dependency injection (eg using EJB and @PersistenceContext annotation) you should not close it by hand. It's the EntityManager that is actually associated to a database connection and closing the EntityManager will actually release the JDBC connection (most often, return it to a pool). For EntityManagerFactory: Closing an EntityManagerFactory would be closer to destroying a whole connection pool. If you want to think JDBC connection, you should think EntityManager. We should not close the factory after every operation. Creating an EntityManagerFactoryis a pretty expensive operation and should be done once for the lifetime of the application (you close it at the end of the application). So, no, you should not close it for each persist/update/delete operation. The EntityManagerFa...

http://weblogs.java.net/blog/archive/2009/08/21/jpa-caching http://www.developer.com/java/ent/article.php/3892261/JPA-20-Cache-Vs-Hibernate-Cache-Differences-in-Approach.htm

The problem maybe caused by the entity class has been cached in the server even you have renamed the package and redeploy the application. For example, com.service.persistence.delivery.A changed to com.service.persistence.reprint.delivery.A. private static String persistenceUnitName = "EclipseLinkWeb"; private static EntityManagerFactory emf = Persistence.createEntityManagerFactory(persistenceUnitName); EntityManagerFactory is acquired statically, and there is no code to free the EntityManagerFactory and other resources before the app starts up again.  This causes the underlying resources to still exist, which have links to the old classloader, and this leads to java.lang.ClassCastException after redeployment. Workaround: Please restart the server. Solution: First, I added the following method to JPAUtil class: public class JPAUtil {   ...       public static void releaseResources() {         if (emf != null) {...

Instead of you dependence Injection for EntityManager by annotation, you can also adopt programmatic EntityManager by the following code. private static EntityManagerFactoryMap buildEmFactories(String name, String persistenceUnit){                 List dsList =  CsvConfigManager.getReprintConfig(name).getDataSourceList();         EntityManagerFactoryMap managerFactories = new EntityManagerFactoryMap();         for (DataSourceEntry ds: dsList) {             HashMap property = new HashMap ();             property.put(TRANSACTION_TYPE, "JTA");             property.put(JTA_DATASOURCE, ds.getJndi());             property.put(CACHE_TYPE_DEFAULT, "NONE");       ...

For JPA, it supports named parameter, such as :parameter1, :parameter2. For native SQL query, it supports positional parameter, such as ?1, ?2.