Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/JPA 2.0/entitymanager updates"

(Issue Summary)
m
Line 26: Line 26:
 
# public Set<String> getSupportedProperties();
 
# public Set<String> getSupportedProperties();
 
# public void clear(Object entity);
 
# public void clear(Object entity);
# public LockModeType getLockMode(Object entity);
 
 
# public <T> T unwrap(Class<T> cls);
 
# public <T> T unwrap(Class<T> cls);
 
# public EntityManagerFactory getEntityManagerFactory();
 
# public EntityManagerFactory getEntityManagerFactory();
 +
# public LockModeType getLockMode(Object entity);
 +
 
 +
 
 +
Here are the implementation details described briefly of the 'getLockMode(Object entity)' method --
 +
In EclipseLink, optimistically and pessimistically locked objects are tracked in 'getOptimisticReadLockObjects()' and
 +
'getPessimisticReadLockObjects()' . The 'getOptimisticReadLockObjects()' returns a map that contains boolean as value .
 +
The 'getPessimisticReadLockObjects()' returns a map that contains an object as value. When an object is locked , the
 +
following has to be checked to determine the lockmodetype-
 +
# OPTIMISTIC --- getOptimisticReadLockObjects() should contain the entity with boolean value 'false'
 +
# PESSIMISTIC ---getPessimisticReadLockObjects() should contain the entity
 +
# OPTIMISTIC_FORCE_INCREMENT ---- getOptimisticReadLockObjects() should contain the entity with boolean value 'true'
 +
#:                                and 'getPessimisticReadLockObjects()' should NOT contain the entity
 +
# PESSIMISTIC_FORCE_INCREMENT---getOptimisticReadLockObjects() should the entity with boolean value 'true'
 +
#:                              and 'getPessimisticReadLockObjects()' should contain the entity.
 +
# NONE --- see [[http://bugs.eclipse.org/263297]
 +
 +
As discussed , when getLockMode(entity) is called on an entity that is removed, it throws 'IllegalArgumentException.' This has been
 +
taken care by checking whether the entity is contained in the active unit of work or not.

Revision as of 17:52, 2 February 2009

Updated EntityManager / Query APIs

JPA 2.0 Root | Enhancement Request

Issue Summary

In JPA 2.0 the specification extends EntityManager and Query APIs. New APIs have been added for getting supported properties and getting the owning Entity Manager Factory.

A new operation 'clear' was also added including a new Cascade Type. Calling clear on an Entity allows the user to remove an Entity and cascaded related entities from the persistence context. Effectively an unregister call.

See JPA 2.0 ED section 3.1.1 and 3.2.6 for details.

General Solution

The implementation of this functionality should be straight forward.

Work Required

  1. Develop test for testing new non-pessimistic locking APIs
    approx 2 days
  2. Update Processing to
    approx 3 days - clear(Object entity)
    approx 2 days - remaining APIs
    approx 2 days - Query Hints

Work Completed

Implementation of the following functions have been completed so far in EM API Update

  1. public Map<String,Object> getProperties();
  2. public Set<String> getSupportedProperties();
  3. public void clear(Object entity);
  4. public <T> T unwrap(Class<T> cls);
  5. public EntityManagerFactory getEntityManagerFactory();
  6. public LockModeType getLockMode(Object entity);


Here are the implementation details described briefly of the 'getLockMode(Object entity)' method -- In EclipseLink, optimistically and pessimistically locked objects are tracked in 'getOptimisticReadLockObjects()' and 'getPessimisticReadLockObjects()' . The 'getOptimisticReadLockObjects()' returns a map that contains boolean as value . The 'getPessimisticReadLockObjects()' returns a map that contains an object as value. When an object is locked , the following has to be checked to determine the lockmodetype-

  1. OPTIMISTIC --- getOptimisticReadLockObjects() should contain the entity with boolean value 'false'
  2. PESSIMISTIC ---getPessimisticReadLockObjects() should contain the entity
  3. OPTIMISTIC_FORCE_INCREMENT ---- getOptimisticReadLockObjects() should contain the entity with boolean value 'true'
    and 'getPessimisticReadLockObjects()' should NOT contain the entity
  4. PESSIMISTIC_FORCE_INCREMENT---getOptimisticReadLockObjects() should the entity with boolean value 'true'
    and 'getPessimisticReadLockObjects()' should contain the entity.
  5. NONE --- see [[1]

As discussed , when getLockMode(entity) is called on an entity that is removed, it throws 'IllegalArgumentException.' This has been taken care by checking whether the entity is contained in the active unit of work or not.

Back to the top