Very often someone ask me what to use for persistence in modern JEE applications: JPA or JDO? Well, JPA is born after JDO and seems to be official supported by Sun since it's part of EJB 3 specification.
But my response is always the same: use a JDO implementation if you want a more powerful tool. JDO 2.1 is a superset of JPA 1 standard.
A feature matrix is available here: http://db.apache.org/jdo/jdo_v_jpa.html
Showing posts with label jdo. Show all posts
Showing posts with label jdo. Show all posts
Saturday, March 01, 2008
Sunday, March 25, 2007
Working on Roma's PersistenceAspect
After the last application developed using Roma Meta Framework I spent much time to refactor and optimize the performance of PersistenceAspect module. Until now Roma always used the JDO detaching mode. It works very well for the most cases, but when you had to execute many operations inside the same transaction or when you don't need to have the objects writeable.
JDO Detaching consumes a lot of CPU resources since the objects are copied and memory since for the same reason. For normal CRUD operation the difference is trascurable, but in long transactions is very sensible.
For this reason I've refactored the PersistenceAspect to have 3 implementations:
- AtomicPersistenceAspect: operations are always atomic and it continue to uses the "classic" detach mode.
- TxPersistenceAspect: operations share the same transaction (you had to call commit/rollback methods!) and you can access to the objects also after the commit/rollback in read-only mode
- NoTxPersistenceAspect: No transaction is used and you can access to the objects also after the commit/rollback in read-only mode
Furthermore you can select the strategy also when you retrieve the object by:
- PersistenceAspect.loadObject()
- Query.setStrategy()
In the next week I'll migrate all CRUD operations to use the NoTx Strategy.
I started also to write a detailed HowTo about the Persistence Strategy.
Stay tuned!
JDO Detaching consumes a lot of CPU resources since the objects are copied and memory since for the same reason. For normal CRUD operation the difference is trascurable, but in long transactions is very sensible.
For this reason I've refactored the PersistenceAspect to have 3 implementations:
- AtomicPersistenceAspect: operations are always atomic and it continue to uses the "classic" detach mode.
- TxPersistenceAspect: operations share the same transaction (you had to call commit/rollback methods!) and you can access to the objects also after the commit/rollback in read-only mode
- NoTxPersistenceAspect: No transaction is used and you can access to the objects also after the commit/rollback in read-only mode
Furthermore you can select the strategy also when you retrieve the object by:
- PersistenceAspect.loadObject()
- Query.setStrategy()
In the next week I'll migrate all CRUD operations to use the NoTx Strategy.
I started also to write a detailed HowTo about the Persistence Strategy.
Stay tuned!
Saturday, November 11, 2006
JPA vs JDO
Many people think that the newest JPA is always the best choice now that first EJB 3.0 implementations are released.
JPA is a subset of Sun Microsystem JDO 2.0 standard. JPOX team published a matrix to compare their.
Today Freshmeat wakes up my email account with the new version of JPOX 1.1.4. I'll try it tonight to release it in the next RomaFramework distribution.
Congratulation JPOX team, the best ORM tool I never used. If you cannot use a pure ODBMS, JPOX is the best choice to work with objects and a Relational DBMS. With no doubts!
JPA is a subset of Sun Microsystem JDO 2.0 standard. JPOX team published a matrix to compare their.
Today Freshmeat wakes up my email account with the new version of JPOX 1.1.4. I'll try it tonight to release it in the next RomaFramework distribution.
Congratulation JPOX team, the best ORM tool I never used. If you cannot use a pure ODBMS, JPOX is the best choice to work with objects and a Relational DBMS. With no doubts!
Subscribe to:
Posts (Atom)
