[jboss-user] [EJB/JBoss] - Re: EntityManager remove does not remove?
You are right. But in case of FlushModeType.AUTO there are enormous SQL queries
performed.
This behaviour you mentioned is defined also in Final Release of JSR-000220 Enterprise
JavaBeans 3.0 http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html -
ejb-3_0-fr-spec-persistence.pdf
3.2.3 Synchronization to the Database
anonymous wrote :
| The EntityManager and Query setFlushMode methods can be used to control
synchronization semantics. The effect of FlushModeType.AUTO is defined in section 3.6.2.
If FlushModeType.COMMIT is specified, flushing will occur at transaction commit; the
persistence provider is permitted, but not required, to perform to flush at other times.
If there is no transaction active, the persistence provider must not flush to the
database.
|
and section 3.6.2 Queries and FlushMode
anonymous wrote :
| When queries are executed within a transaction, if FlushModeType.AUTO is set on the
Query object, or if the flush mode setting for the persistence context is AUTO (the
default) and a flush mode setting has not been specified for the Query object, the
persistence provider is responsible for ensuring that all updates to the state of all
entities in the persistence context which could potentially affect the result of the query
are visible to the processing of the query. The persistence provider implementation may
achieve this by flushing those entities to the database or by some other means. If
FlushMode-Type.COMMIT is set, the effect of updates made to entities in the persistence
context upon queries is unspecified.
|
Fortunately I found also in section 3.2.5 Managed Instances
anonymous wrote :
| It is the responsibility of the application to insure that an instance is managed in
only a single persistence context.
| ...
| The contains method returns false:
| . If the remove method has been called on the entity, or the remove operation has been
cascaded to it.
|
SOLUTION: Well my solution for this problem is to check using method
EntityManager.contains(..) that returned object (by EJBQL) is contained in EntityManager
instance.
Changes in my code:
if ((pv.getPlanId() == newDBPlanVersion.getPlanId()) &&
(!pv.equals(newDBPlanVersion)) && em.contains(pv)){
| public DBPlanVersion addPlanVersion(int planId, String description) {
| DBPlanVersion newDBPlanVersion = new DBPlanVersion();
| newDBPlanVersion.setPlanId(planId);
| newDBPlanVersion.setDescription(description);
| // Lets check whether plan version with the same plan id already exists
| for (DBPlanVersion pv : findAll()) {
| if ((pv.getPlanId() == newDBPlanVersion.getPlanId()) &&
(!pv.equals(newDBPlanVersion)) && em.contains(pv)) {
| throw new RuntimeException("Unable to insert plan version with
the same planId = " + pv.getPlanId());
| }
| }
| em.persist(newDBPlanVersion);
| return newDBPlanVersion;
| }
|
It is fully functional also with caching enabled on DBPlanVersion and caching on queries
| @Entity(name = "DBPlanVersion)
| @Table(name = "PLAN_VERSION")
| @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)
| @NamedQueries({
| @NamedQuery(name = DBPlanVersion.findAll, query = "SELECT a FROM DBPlanVersion
a", hints = {(a)QueryHint(name="org.hibernate.cacheable",
value="true")}),
| @NamedQuery(name = "DBPlanVersion.findByPlanId, query = "SELECT a FROM
DBPlanVersion a WHERE a.planId = :planId", hints =
{(a)QueryHint(name="org.hibernate.cacheable", value="true")} )
| })
| public static DBPlanVersion implements Serializable {
| // ... the same code as previous post
| }
|
EJB3/JBoss gurus, may I use this solution?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146508#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...