Experiences on JPA persistence providers other than standard SAP's

Question

Hi developers,
in this thread I would like to gather experiences from all those who have tried using JPA persistence providers other than SAP standard implementation in productive environments
It would be very interesting if you could share you experiences, for instance with regards to:
- advantages of a specific implementation
- disadvantages (if any)
- new features available (e.g. Lazy support for Lob and single-value relationships)
- ease of transport (did you manage to somehow use the java dictionary DCs or what?)
- ease of build (e.g. EclipseLink requires additional build plugins to be developed)
- ease of overall setup: how long did it take to set the DI stuff up (SLD SC creation/track creation/check-in/check-out/activate/transport/...)?
thank you so much for sharing your experiences.
Regards
Vincenzo

Answer 1

Hi Vincenco,
yes, semantic IDs do not have a place in JPA. Semantic keys are needed, but not as IDs.
Both SAP JPA and EclipseLink use @GenerationType.TABLE generation if you define @GenerationType.AUTO. ("AUTO" just means that the persistence provider "should pick an appropriate strategy for the particular database" (javadoc)
Both TABLE and SEQUENCE are somewhat automatic.
I guess the fact of lost-values is because the fetching of IDs is done in another transaction (probably for performance reasons, not to have the sequence table as a bottle neck).
On Oracle, the combination of allocationSize on JPA side and INCREMENT BY / CACHE on Database side is as follows: allocationSize must be equal to INCREMENT BY, but JPA uses the intermediate numbers (which is not the case in normal (PL)SQL programming. There is no annotation-JPA-pendant to CACHE. But that JPA uses the intermediate numbers from memory may be considered as a JPA way of sequence caching (that may be further improved by Sequence CACHE for really big mass insers in one transaction).
CACHE>1 will give you lost values even with allocationSize = Increment BY = 1.
On the other hand, allocationSize=1 may give bad performance on mass inserts because the JPA provider must ask the database for every instance. allocationSize>1 (e.g. 20) is better but will again yield lost values. (But who cares with "long"?)
There is one important issue with both automated value creation strategies - GeneratorType.TABLE and GeneratorType.SEQUENCE: The ID cannot be set by yourself on instantiation of an Entity object. JPA spec defines that the ID is set at the latest on EntityManager.flush or EntityManager.commit, which is sometimes too late if you have container managed transaction boundaries.
But both SAP JPA and EclipseLink assure that the ID with Table and Sequence is set already after call EntityManager.persist(newObject). This improves a lot, but may be not enough.
Example:
@Entity(name="T_ORDER")
public class Order {
     @OneToMany(targetEntity=OrderItem.class, mappedBy="order", cascade=CascadeType.ALL)
     private List<OrderItem> items = new ArrayList<OrderItem>();
     public void addItem (OrderItem item) {
          this.items.add(item);
          item.setOrder(this);
@Entity(name="T_ORDERITEM")
public class OrderItem {
     @ManyToOne(targetEntity = Order.class)
     private Order order;
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
Order o = new Order();
OrderItem i1 = new OrderItem();
o.addItem(i1);
em.persist(o);
OrderItem i2 = new OrderItem();
o.addItem(i2);
At the end of this snippet, o and i1 have ID != null but i2 has ID==null. there is no way to "auto-persist" an object which gets into a relation to an already persisted object. i2 gets an ID!= null after flush or commit.
This may be tricky if your business logic that adds items is "pojo" without acces to EntityManager or if you do not want to mess up your business logic with flushes.
How to "broadcast" the  unique IDs of just inserted order items to the User Interface if they are not yet set in the last line of your SLSB?
We switched to simple UUIDs that are generated on instanciation. long VARCHAR2s, but it works fine and is very common.
Regards
-Rolf